Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"If either the a element has a download attribut..." #2116

Closed
cdumez opened this issue Nov 29, 2016 · 2 comments
Closed

"If either the a element has a download attribut..." #2116

cdumez opened this issue Nov 29, 2016 · 2 comments
Assignees
@domenic

Comments

@cdumez
Copy link

cdumez commented Nov 29, 2016

https://html.spec.whatwg.org/#the-a-element

If either the a element has a download attribute and the algorithm is not triggered by user activation; or, if the user has not indicated a specific browsing context for following the link, and the element's target attribute is present, and applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute as the browsing context name, would result in there not being a chosen browsing context, then run these substeps:​

If there is an entry settings object, throw an "InvalidAccessError" DOMException.

Abort these steps without following the hyperlink.

Both Gecko and Blink seem to allow synthetic clicks on anchors that have a download attribute. WebKit used to follow the specification here but it caused compatibility issues. Therefore, we are relaxing the requirements and allowing synthetic clicks:
https://bugs.webkit.org/show_bug.cgi?id=165148

Should we update the specification to match the behavior of existing browsers, especially considering matching the specification (if I understand the specification correctly) seems to break existing Web content.
hubot pushed a commit to WebKit/WebKit-http that referenced this issue Nov 29, 2016
Can't download move.simple.com direct deposit transition PDF: Non use…
88d73c9 
…r-triggered activations of anchors that have a download attribute are ignored

https://bugs.webkit.org/show_bug.cgi?id=165148
<rdar://problem/29421771>

Reviewed by Daniel Bates.

Source/WebCore:

We were ignoring non user-triggered activations of anchors that have a
download attribute which is stricter than Chrome and Firefox and breaks
downloads on move.simple.com. This patch relaxes our policy to allow
simulated clicks on such links, similarly to other browsers.

Web authors can anyway already trigger downloads using script by setting
window.location to a specific URL and serving to right HTTP headers to
trigger a download.

Note that our previous behavior matches the current version of the
specification so I also filed a bug against the HTML specification to
see if we can get it changed to match the behavior of browsers:
- whatwg/html#2116

No new tests, updated existing test.

* html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::handleClick):

LayoutTests:

Update existing test to reflect behavior change.

* fast/dom/HTMLAnchorElement/anchor-download-synthetic-click-expected.txt:
* fast/dom/HTMLAnchorElement/anchor-download-synthetic-click.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@209091 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@annevk
Copy link
Member

annevk commented Nov 30, 2016

Simple demo: data:text/html,<a href=data:,hi download></a><script>document.querySelector("a").click()</script>.

I guess we should change the standard, but it does seem rather annoying to just let sites download stuff without user interaction. (In Firefox you do still get a prompt, in Chrome it goes directly into the Downloads/ folder.)

@annevk annevk added the good first issue Ideal for someone new to a WHATWG standard or software project label Nov 30, 2016
@zcorpan
Copy link
Member

zcorpan commented Nov 30, 2016

It is already possible to download stuff without user interaction without the download attribute, e.g.

<!DOCTYPE html>
<iframe src="data:application/octet-stream,hi">

@domenic domenic self-assigned this Dec 5, 2016
@domenic domenic removed the good first issue Ideal for someone new to a WHATWG standard or software project label Dec 5, 2016
domenic added a commit that referenced this issue Dec 5, 2016
@domenic
Allow <a>/<area> with download="" to not require user activation
22d24cb 
Fixes #2116, wherein it is documented that this restriction is not
supported in any existing engines and attempting to do so in WebKit
proved not web-compatible.

Also helps with #1431.
@domenic domenic mentioned this issue Dec 5, 2016
Merged
domenic added a commit to web-platform-tests/wpt that referenced this issue Dec 5, 2016
@domenic
Add tests that <a>/<area> can be downloaded without user interaction
5c12cd9 
That is, that calling .click() does not throw at least, as it used to
per-spec. Matches the HTML change at
whatwg/html#2136 per the HTML bug report at
whatwg/html#2116.
@domenic domenic mentioned this issue Dec 5, 2016
Merged
domenic added a commit that referenced this issue Dec 6, 2016
@domenic
Allow <a>/<area> with download="" to not require user activation
5de03c7 
Fixes #2116, wherein it is documented that this restriction is not
supported in any existing engines and attempting to do so in WebKit
proved not web-compatible.

Also helps with #1431.
domenic added a commit to web-platform-tests/wpt that referenced this issue Feb 8, 2017
@domenic
Add tests that <a>/<area> can be downloaded without user interaction
b9a944d 
That is, that calling .click() does not throw at least, as it used to
per-spec. Matches the HTML change at
whatwg/html#2136 per the HTML bug report at
whatwg/html#2116.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@domenic
Allow <a>/<area> with download="" to not require user activation
051e305 
Fixes whatwg#2116, wherein it is documented that this restriction is not
supported in any existing engines and attempting to do so in WebKit
proved not web-compatible.

Also helps with whatwg#1431.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@domenic domenic

Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@zcorpan @domenic @cdumez @annevk