Hi I have an anchor tag with download attribute which when clicked downloads the image from the url defined in href. This works fine in Chrome but in Firefox it takes to the image in the browser. Is there any way we can make this work in FF
image
The problem with this is that in Firefox this only works for files with the same origin. From MDN:
In Firefox 20 this attribute is only honored for links to resources with the same-origin.
I see three solutions:
If you own the target image and has control over it, you should serve it from the same domain as the page where you put the link.
Set up a reverse proxy to serve the images through the same origin
Again, if you own the target site, you could serve it with a Content-Type: application/octet-stream header which will force the browser to download the image regardless of how the download link looks
Related
I'm working on a web app where user uploaded images are hosted on a cdn. These images are displayed within an svg since I'm using d3 to display those images in a bubble style interface. The <image> tag within the svg has crossorigin set to "anonymous" but those images get blocked by Firefox since the request to fetch them are made with Sec-Fetch-mode header set to 'no-cors'. Setting crossorigin to "anonymous" on an <img /> tag works fine but with an <image> tag, it doesn't work.
This is the error message from Firefox when it blocks the images:
The resource at “https://cdn.server.com/imagepath.jpg” was blocked due to its Cross-Origin-Resource-Policy header (or lack thereof). See https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)#
How do I make my images load properly/reliably on Firefox?
I'm on Firefox version 110. The images both in <img /> tag and in the svg work fine with Chrome which seems to set the appropriate header.
Another peculiar thing is that the images load fine when running the app on localhost though the browser makes the same request with the same headers both times. This is a react app setup with Vitejs and vite-pwa if that helps.
I want to embed base64 encoded string of pdf into an html template.
<iframe src="data:application/pdf;base64, encodeURI(pdfstring)"></iframe>
This works fine in chrome and edge but showing blank page in IE 11.I do not want to download it.Is there a fix for IE11
It doesn't work because IE doesn't support iframe with data url as src attribute. You could check it in caniuse. It shows that the support is limited to images and linked resources like CSS or JS in IE. Please also check this documentation:
Data URIs are supported only for the following elements and/or
attributes.
object (images only)
img
input type=image
link
CSS declarations that accept a URL, such as background, backgroundImage, and so on.
You can only do what like the accepted answer says:
The only workaround for this is to return your PDF content from a HTTP/HTTPS or FTP URI and use that as the source of the IFRAME.
I'm using file-saver, npm package to download SVG URL image, which I display on one of my pages, but on Firefox and older chrome versions when I press the button to download the image, I'm being redirect instead of downloading the image
The native way would be to use the Content-Disposition HTTP header to instruct browsers to trigger file download instead of showing the content. For example:
Content-Disposition: attachment; filename="image.svg"
For the download links, you should also set the download attribute. This will prevent navigation to a resource. It will start a download instead.
For legacy IE, you may fallback to use navigator.msSaveBlob to trigger a manual download of a prepared Blob (you must first download the contents, then convert it to a Blob object so IE can save the result).
I'm seeing some unexpected behavior when trying to load images on firefox. In my web application, I've built a graph. When I hover points on the graph, a tooltip is rendered, and within that tooltip an image (along with some text). When I render this on firefox, the image begins to show loaded content, and then once fully loaded, is replaced with the broken page icon. (See imgur gif below).
The images are being loaded from Amazon S3, which could be relevant. Also, this tooltip is being rendered by Recharts library, in plain js, the component is being imported in my React app.
The line to load the image is simply:
<img src={image_url} width="336px" />
This occurs on my current install of FF (windows 10) as well as a MacOSX fresh firefox install (with no add-ons). This does not occur in any chrome installation (tested on 5+ computers) nor in microsoft edge.
I inspected the network calls to load the images and found only these differences (but you might be able to see something I am missing in the live link to the webapp below):
In chrome, the Referrer Policy was strict-origin-when-cross-origin, while in FF it defaulted to no-referrer-when-downgrade (however I locally set the firefox referral policy value (via attribute on the img) to strict-origin-when-cross-origin and origin-when-cross-origin, no change occurred).
Here is the chrome Accept header: image/avif,image/webp,image/apng,image/*,*/*;q=0.8
versus the firefox: image/webp,*/*
Lastly, Accept-Language was different, with chrome en-US,en;q=0.9 when Firefox has en-US,en;q=0.5.
Here's a webm + gif displaying the behavior I'm seeing:
https://imgur.com/a/x66AWoc
Here's the live website where this is occurring:
http://52.53.193.14:3000/viewcount/esl_csgo/2020-10-11_09-11-21
As #Leandro pointed out in the comments, the problem was image size.
did you try resize your image to some smaller? You are using an incredible size for thumbail, you should use 2 images. I still believe you have two problems, 1) the size 2) the cross site security problem (resolved with politics on the server side)
I didn't know that the larger images would break, that certainly surprised me. I expect it might have to do with too many large images overloading the allowed memory of the page. (However this occurred even on the first load).
EDIT:
FOUND MY MISTAKE:
line 3 in this example, the $(this) selector isn't valid in this case. So the command is skipped, the download attribute isn't set and instead of downloading, the browser tries to navigate to the dataUrl, which is prohibited. Cue errors.
I have a PWA that stores images as base64 pngs. I want to give users the option to download them to their device.
Previously I used this really simple code where myAnchor is an anchor-tag in my HTML and pic contains the base64 png:
function imgDownload(pic) {
$('#myAnchor').attr('href', pic);
$(this).attr('download', 'image.png');
$('#myAnchor')[0].click();}
So: simply set href to the image, set download attribute and filename, then trigger the download by clicking the link. But either Chrome 60 or 61 broke that - apparently for security reasons -, it now results in this error:
Not allowed to navigate top frame to data URL: [my b64 png]
Is there a (preferrably not too complex) client-side alternative to achieve the same functionality? It only has to work in Chrome, more browser compatibility is nice of course, but not neccessary.