[Webkit-unassigned] [Bug 64580] Add support for download='filename' in anchors

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 26 08:43:57 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=64580





--- Comment #79 from Ian 'Hixie' Hickson <ian at hixie.ch>  2011-07-26 08:43:56 PST ---
I strongly agree with ap that dispatchEvent()-generated events should not cause a link to do anything. But that's got nothing to do with the changes for download=""; the spec has long said that script-dispatched events do not have UA-provided default actions, since the event model is that the default action is, by definition, whatever the code that dispatched the event makes it. When script dispatches the event, there is no browser-provided default action since the browser didn't dispatch the event, and thus the link should do nothing.

However, when the click() method is called, it _should_ do something, because the click() method both dispatches the event *and does the default action*, again by definition. Now in this case there are two things the spec currently says should not happen that would happen in the case of a real trusted click: popups shouldn't open, and nothing should happen if the download="" attribute is present.

I also think we should change the spec to say that if you navigate to a URL that then triggers a download, the download shouldn't happen. Currently this isn't in the spec. Unfortunately this not being in the spec means that the restriction on download="" is pretty lame, since it means you can do the downloads with a bunch of iframes but not with a bunch of links.

In the medium term I intend to make the spec consistent so that either no downloads are allowed without user gesture, or all downloads triggered from click() will work as if they had a user gesture. I do not intend to change the thing with synthetic events (those should not ever work, that's a long-standing bug in WebKit), and do not intend to change the popup blocking.

HTH.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list