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

[bugzilla-daemon at webkit.org]

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





--- Comment #75 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-07-25 11:42:17 PST ---
(In reply to comment #73)
> Is there a reason for Google contributors to want making synthetic events work here?

It is not about enabling a feature for Google.  AFAIK, the customer use case would be solved with the restricted form of a at download.

My objection is that restricting a at download adds complexity to the platform in a way that is inconsistent with other features of the platform.

Script can already create as many downloads as it likes by:

1-  Creating a Data URL, Blob URL or FileSystem URL with mime type application/octet-stream, and navigating an iframe to that Data URL.  (The FileSystem case just requires that you use an unknown file extension.)

2-  Arranging to have a server provide a C-D header, and navigating an iframe to that HTTP URL.

This means that placing a restriction on a at download doesn't prevent someone who wishes to spam the browser's download system.  The browser will need to have anti-spam measures to manage those vectors.

Second, on the topic of user-gesture.  If we implement FileSaver, then we will not have a click target.  We will instead need to rely on user-gesture if we wanted to limit FileSavers use.  If we are going to limit FileSaver based on user-gesture, then we might as well use a consistent policy for scripts click()ing an anchor tag, otherwise it is just inconsistent policy.

As you can see, I'm arguing for consistency in the platform.  I think this is a good goal.

My preference from most to least preferred:

1) No web platform restrictions on a at download and FileSaver.  This is consistent with navigating an iframe.

2) Restrict a at download and FileSaver based on whether or not there is a user gesture.

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