The download attribute on an anchor element should set the name of the downloaded resource to the value of the download attribute. In the current version of chrome, the download attribute doesn't, however, change the name. Is this not anymore supported? Anything changed?
Here is a post explaining the functioning of the download attrib: http://updates.html5rocks.com/2011/08/Downloading-resources-in-HTML5-a-download
If it worked as expected, the name of the downloaded resource would be MyGoogleLogo. It is, however, the last element (file) of the href.
It seems that the download attribute works only when the resource is retrieved via HTTP from the same server as the linking document. So if you have
<a href=foo.txt download=something.txt>xxx</a>
on a web page, it works, but if it is in a local file, it does not; neither does it work if a web page refers to a resource on another server. By “works” I mean setting the filename; even when it does not “work” in this sense on Chrome (or Firefox), it causes a pure download instead of navigation to the resource, i.e. the resource is downloaded as a file but not opened in the browser.
According to MDN info, “In Firefox 20 this attribute is only honored for links to resources with the same-origin.” This seems to apply to current Firefox, too, in the stronger sense that the download attribute is completely ignored for cross-origin requests.
Related
I'm trying to upload my resume to a company's website and I'm getting a C:\fakepath\myfilename,
Does this means that my file can't be uploaded to the website? or is it just for security reasons?
(I tried uploading with Microsoft Edge and Chrome)
When a file is chosen using an <input type="file">, the real path to the source file is not shown in the input's value attribute for obvious security reasons. Instead, the filename is shown, with C:\fakepath\ appended to the beginning of it. There are some historical reasons for this quirk, but it is supported across all modern browsers, and in fact is defined in the spec.
So, the browser shows the fake path for security reasons and it will not cause any issue with the file upload functionality. The file upload will work fine.
References:
Refer to the second point of the Notes section
FileUpload in Chrome giving some fake path value
FakePath issue in Chrome browser
It seems to me that HTML5 download links bypasses any registered Service-Worker? Is this intended design?
<a href="/assets/images/i_am_cached_by_service_worker.png" download>link</a>
Both in Chrome v.62 and in Firefox v.57 this seems to be the case.
In Firefox it says it picked the .png file from the browser cache (304, not changed) which lies beyond the service-worker layer (note: all files were served with no-cache originally).
In Chrome the download activity doesn't even show in the Network tab at all.
Only if I go to chrome://net-internals/#events do I see it and there it never calls i.e. "SERVICE_WORKER_START_REQUEST" which seemingly all other network activities does. It just bypasses the Service-Worker layer and goes straight to the server.
Note: If I make a traditional download link:
link
then it will be handled by Service-Worker just fine (assuming registered Service-Worker scope is at URL root).
2nd. Note: In my case the Service-Worker scope is NOT at root (/region/shop) and I use a workaround where I have every attachment links be within that same scope, ensuring it's handled by the Service-Worker, but from inside the Server-Worker itself I can re-direct that request to wherever suits me (outside of scope).
Hash '#' breaks browser download behavior however (when using just a normal href link or target="_blank") and is excluded from url in link element. Registered Service-Worker scope should therefor not include '#' char for SPA's. This is all a workaround however and doesn't answer the original question.
Trying to get this file to be downloaded and renamed to "image.png", but every time I click on the download button, the file is always downloaded with the name: "leisa_christmas_false_color.png". Would appreciate any help, thanks.
<a id="download" href="https://www.nasa.gov/sites/default/files/styles/image_card_4x3_ratio/public/thumbnails/image/leisa_christmas_false_color.png" download="image.png">Download</a>
Firefox only allows users to download files of the same origin due to a security concern. The file must come from your own server or domain name, otherwise it will be opened in the browser.
While downloading cross-origin files is allowed in Chrome and the latest Opera (with Chromium/Blink), they will both ignore the attribute value. In other words, the file name will remain unchanged.
Don't use an extension like '.png' in the download attribute. You can't change the extension; it will be automaticly added.
Btw not every Browser actually support the download attribute. For more information take a look here: http://www.w3schools.com/tags/att_a_download.asp
So ive been through several posts and searches, but im still at a loss for how to get Chrome to display images when the src attribute uses a file thats located on another server. Im getting the image and setting its path via a custom file browser that Im hooking into CKeditor with. Works fine in IE, just not chrome.
This is for an intranet, and some of the image content is stored off of the web server. Although IE displays fine, it seems that Chrome does not like to display images with the src attribute is of a format like
file://server_name/share_name/folder_1/file_1.png
Strange, even though Chrome will pass the users identity, so its not a security issue. Also, if I take the path and directly paste it in the url window of Chrome, it displays fine. Just not when a img src value.
If this was just a page on its own, I could use a custom handler and write to the response stream, but this needs to work with a content editor.
Id like to include Chrome since many of our users have it and use it daily, but our default is IE.
Are there any file url schemes, or Chrome settings that will override these issues?
The issue may not be the image or URL format. I'd wager that it's browser security restrictions.
To ensure that maliciously designed web pages can't access a user's local files, accessing any data from the user's filesystem (especially network drives) is generally disallowed in most modern browsers. (At least in their default configuration. There may be policies or runtime parameters to override these for testing purposes such as Chrome's --disable-web-security parameter, but these are purposefully difficult to turn off.)
If you want the content to display across all browsers, you'll likely need to deliver it via HTTP(s) like the rest of the page content.
In previous version of chrome, on a webpage with the following:
<script>
document.write('<plaintext>');
</script>
<img src="http://example.com/image.jpg">
the image would not be downloaded. At some point a chrome update changed this behavior. Now when I look at the network tab, I see the image is downloaded. (fiddle here: https://jsfiddle.net/doojunqx/)
I have a script that is on a page, I would like to use this script to stop the browser from downloading (using up network bandwidth) for images and other assets that are unwanted and below my script tag.
Mobify does something similar here:
http://cdn.mobify.com/mobifyjs/examples/capturing-grumpycat/index.html
As they say on the page "Open your web inspector and note the original imgs did not load." However, when I open chrome developer tools and look at the network tab, I see the original images ARE now loading. I'm not sure what version of chrome changed this, but I think it is recent, within the last month or two.
Is there any way to force chrome back to the old behavior? Or any other way to stop these unwanted assets from loading?
Thanks,
Great question, and you're correct that it is a recent change in Chromium that affected the plaintext tag behaviour. In versions up to and including version 42.*, the HTML document parser would not spawn an asynchronous parsing thread until an external resource was found in the original HTML document. Once such a resource was found, an asynchronous thread would be spawned that would aggressively download all resources references within the HTML.
The recent change simplified the parsing behaviour by moving all document parsing to the asynchronous thread which now kicks off automatically. Whereas before, using the plaintext tag would ensure that no resources would be loaded if it was inserted before the first external resource, the plaintext tag is now racy as resources will download up to the moment the plaintext tag is executed in the main HTML document. As there is a time delay for the script to execute, an unknown number of resources will be retrieved.
There is as of yet no solution to this new behaviour, nor is there a way to disable the preload scanner as you would like. You will need to rely on workarounds such as polyfills to control your resource downloads. This new behaviour is only present in all versions of Chrome >= 43.* and has not been implemented in Safari, Firefox, or other browsers.