I have this extremely simple HTML:
<a download="red.png"
href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==">
Static
</a>
In Chrome or Firefox, it downloads red.png as expected.
In IE, it navigates to an error page. See it on JSFiddle.
Now, I know the download attribute is not supported in IE, and that's fine. I'd still expect it to navigate to the "file", allowing the user to save it. Instead, it's navigating to an error page.
Is there a way to get around this problem? The Data URI is generated client-side; creating the file on the server is not an option.
Edit: MSDN says:
For security reasons, data URIs are restricted to downloaded
resources. Data URIs cannot be used for navigation, for scripting, or
to populate frame or iframe elements.
...which I read as "Even though every other browser supports this, we don't know how to do it". So, still looking for a workaround to download a file generated on the client.
Since IE does not support either navigating to a data URI, nor the download attribute, the solution is to use navigator.msSaveBlob to generate the file and prompt the user to save it.
Credit goes to this answer.
Related
Is there any way I can find out what the latest file Selenium downloaded was, and from where (what URL) it was downloaded?
I am fetching files from a large number of sites (that I do not control) by clicking on elements, and my problem is that I do not know how the files are downloaded. Sometimes it is just an <a> element, sometimes there is a Javascript event attached to some element, or form (not always obvious from inspection), and so on, and so on.
So I though the easiest would be to just do my clicks, and then check what landed in the download folder. But then I have no idea where that file came from, and I also need to store the url.
For files that can be displayed inline, I can, of course, open them in the browser and get the driver.current_url. This is very convenient for file formats where it actually works, so if there is a way to force e.g. Firefox or Chrome to open all files inline, that would also be an option. (I am aware of one such extension. That extension, however, requires some user interaction in a OS file dialogue window, and that seems like overkill here)
Possible solutions
Firefox: Read moz_downloads from downloads.sqlite, in the FF SQLite DB
Chrome: Read the corresponding SQLite db for Chrome/ium
Write browser extensions that modifies the mimetype of visited pages, so that all files are opened as plain in the browser, and the URLs can be accessed from there.
How I understanding selenium it only insert js to page, that mean that you can interact only with web page but not with browser futures.
But you can do like in this post How to access Google Chrome browser history programmatically on local machine if that files are in download history you can find them there.
In both image and script tags.
My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?
Is this when you want to restrict the ability of others to access your scripts and image?
Images:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin
Scripts:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
The answer can be found in the specification.
For img:
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.
and for script:
The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
This is how we have successfully used crossorigin attribute it in a script tag:
Problem we had: We were trying to log js errors in the server using window.onerror
Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.
It turns out that the native implementation in chrome to report errors
if (securityOrigin()->canRequest(targetUrl)) {
message = errorMessage;
line = lineNumber;
sourceName = sourceURL;
} else {
message = "Script error.";
sourceName = String();
line = 0;
}
will send message as Script error. if the requested static asset violates the browser's same-origin policy.
In our case we were serving the static asset from a cdn.
The way we solved it was adding the crossorigin attribute to the script tag.
P.S. Got all the info from this answer
CORS-enabled images can be reused in the element without being tainted. The allowed values are:
The page already answers your question.
If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.
MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image
Is this when you want to restrict the ability of others to access your scripts and image?
No.
If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:
file://D:/wwwroot/mydir/mytestpage.html
and your Javascript file and images are being fetched from, say:
file://D:/wwwroot/mydir/mycode.js
file://D:/wwwroot/mydir/myImage.png
then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.
For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.
Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.
I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.
I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.
I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.
Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;
Step 2: Set the target to something like the following:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.
Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.
In both image and script tags.
My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?
Is this when you want to restrict the ability of others to access your scripts and image?
Images:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin
Scripts:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
The answer can be found in the specification.
For img:
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.
and for script:
The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
This is how we have successfully used crossorigin attribute it in a script tag:
Problem we had: We were trying to log js errors in the server using window.onerror
Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.
It turns out that the native implementation in chrome to report errors
if (securityOrigin()->canRequest(targetUrl)) {
message = errorMessage;
line = lineNumber;
sourceName = sourceURL;
} else {
message = "Script error.";
sourceName = String();
line = 0;
}
will send message as Script error. if the requested static asset violates the browser's same-origin policy.
In our case we were serving the static asset from a cdn.
The way we solved it was adding the crossorigin attribute to the script tag.
P.S. Got all the info from this answer
CORS-enabled images can be reused in the element without being tainted. The allowed values are:
The page already answers your question.
If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.
MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image
Is this when you want to restrict the ability of others to access your scripts and image?
No.
If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:
file://D:/wwwroot/mydir/mytestpage.html
and your Javascript file and images are being fetched from, say:
file://D:/wwwroot/mydir/mycode.js
file://D:/wwwroot/mydir/myImage.png
then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.
For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.
Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.
I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.
I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.
I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.
Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;
Step 2: Set the target to something like the following:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.
Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.
Im trying to dynamically create a CSV file using javascript that the user can download. This only has to work in IE.
The html the javascript generates looks something like this
CSV
Which seams to work fine in chrome but IE10 just breaks.
Is there a better way to dynamically create a file using JavaScript and then give the user a link to download it? I cant use PHP as the entire system needs to run on the client-side due to restrictions placed by the user. The system all needs to work on a touch screen (with no right click option) so the link needs to give the user the ability to download, not open the file.
Internet Explorer 10 doesn't support the data protocol on the a element. Per the documentation, the only supported elements/attributes are the following:
object (images only)
img
input type=image
link
CSS declarations that accept a URL, such as background, backgroundImage, and so on.
You should know that what you're attempting to do smells like a phishing attempt; for this reason you shouldn't expect browsers to support this pattern. You can read more about data-uri phishing in the paper Phishing by data URI.
I had the same problem, I download the data uri in this way with Chrome:
var link = document.createElement("a");
link.download = dataItem.Filename;
link.href = data;
link.click();
But it does not work in Internet Explorer. I have found a library that works in Internet Explorer, https://github.com/rndme/download
The only issue for me is the dowload of files with longer MIME type like odt, docx, etc. For all the other kind of files it look great!
i have recently started using Senchs extJS.. when we see the source file it only displays what ever is the written code, but what the style has applied or any script that added later is not there in the "View Source"
Same for AJAX, when we load anything in any container, it is not there...
but if we're using Chrome and we inspect the element, it show everything....
WHY this behavior?
View Source in browsers typically only displays the downloaded source without running anything at all (including any JS that would modify the DOM). In fact, at least Chrome will create a separate request when you view source to get that code.
As for the reason why, I'm not sure exactly. This is just the standard and is the way that "view source" has worked for long before I was ever a web developer. It is similar to doing a raw HTTP request (i.e. you just get the source; nothing runs to change it). The term "Source" indicates the origin of what you have received, unmodified (think "source code.")
Because that's just how it works. View source only shows the page when it was first served up to the browser.