1344648 - Add way for WebExtensions to let users chose custom actions to downloads

Status: UNCONFIRMED

(WebExtensions :: General, enhancement, P5)

Description

[est31]

It should be possible for Web Extensions to add custom actions to the "what to do with this file" menu, currently located at `chrome://mozapps/content/downloads/unknownContentType.xul`

Right now its possible with a XUL overlay, but it seems you want to deprecate the general ability to do this.

Therefore, I'm proposing a more limited API tailored to the use case:

1. You should be able to add a custom action (a radiobutton) to the list of actions.
2. You should have access to the URI
3. You should be able to close the dialog (from the WebExtension code) without causing any further action by firefox itself, like a download.

Blocks bug 1344646

Comment 1

[est31]

Oh, it seems to be already doable with the onHeadersReceived callback. nvm then!

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onHeadersReceived

Comment 2

[est31]

Wrong bug, sorry :)

Comment 3

[est31]

I've managed to display a dialog inside the tab view, but its not the same experience for the users. I essentially have to re-write the "what to do with this file" dialog to display my custom message, and guess from the mime type and content disposition whether that dialog will be displayed in the first place. Lots of duplication, and even more chance for things to go wrong.

Comment 4

[Shane Caraveo (:mixedpuppy)]

This seems like navigator.registerContentHandler functionality, which is not fully supported in firefox beyond a couple built in mime types.

Comment 5

[est31]

Thanks Shane for your reply. I think you have misunderstood my request. My request is unrelated to navigator.registerContentHandler.

The add on's purpose is mostly to prevent forced downloads by websites. The websites implement such force downloads by either the official way, setting the content disposition header to attachment [1], or the unofficial way, setting the mime type to application/octet-stream (see also [2]). Then, firefox shows a "what to do with this file" dialog. You should be familiar with it, if not, you can get the chrome url at comment 0 to get a look. My request is to make that dialog customizeable, maybe not completely, but at least to allow additional radio button entries with text and drop down lists for chosing the mime type [3] (see [4] for how I would most prefer it to look like). If you only want to allow radio buttons with text labels (and no drop down lists) that would be a good start already.

I imagine some function like:

browser.unknownContentTypeDialog.addRadioButton(<text or array>, <callback>)

* <text or array> contains either some entry like "Open in browser" or an array like ["Open in browser", ["server sent MIME", "application/pdf", "image/png", ...]] where arrays map to radio buttons and strings to labels.

* <callback> would be some function(url, data) where data is some representation of the dropdown list choice, and which gets called if the radio button was chosen and the user chose to click "Ok".

Repeating, I'd think it would be a good first step to have only text label support, and no drop down list support. The original add on had drop downs [4], but I think I can innovate on that.

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#As_a_response_header_for_the_main_body
[2]: http://stackoverflow.com/a/20509354
[3]: optimally, I could make the add on autodetect the MIME type, then the drop down list requirement would be gone. For this, maybe having the ability to peek into the first few bytes of a file would be useful to extract its magic sequence. Maybe I could send a third request just to extract that info...
[4]: https://addons.cdn.mozilla.net/user-media/previews/full/23/23688.png

Comment 6

[Shane Caraveo (:mixedpuppy)]

We wouldn't do an api like you described as it locks us tightly into the way the browser ui works right now.

What we should look at is whether webrequest can catch the headers of a download and suspend the download.  If that is not possible, then we should consider making it possible.  Might also consider whether downloads.onDeterminingFilename (or any other unimplemented api) is part of this, see bug 1245652, but I haven't researched that.

At that point, we could use some new api such as described in Bug 1340930 where the addon could implement it's own UI for helping with the possible choices.

So the process could look like:

webrequest.onheadersrecieved
  analyze headers for download
  if need to do something, 
    suspend download
    show addon ui
    update download info and/or received headers based on user input
    resume download

There is also bug 1323414 that could play some part in this, you should be able to peek at the bytes of the download.  I'd imagine a similar process:

downloads.streamlistener
  analyze bytes of download
  if need to do something, 
    suspend download
    show addon ui
    update download info and/or received headers based on user input
    resume download

Comment 7

[est31]

> What we should look at is whether webrequest can catch the headers of a download and suspend the download.

Something like that is already possible. In fact, that part of  I can already do the following:

1. find out the headers of a response
2. guess whether those headers will yield in that dialog being shown
3. if yes, set the tab's url to a page I control via browser.extension.getURL("dispatch.html")#url-of-the-request
4. on that page, show the buttons about how to continue.
5. re-issue the request for the url, depending on which button has been clicked, maybe overriding the given headers.

I've implemented it in [1] if you want to know the details.

However, there are some problems with that approach, as I've already partly outlined in comment 3.

Step 2 would duplicate logic the browser does, and may not work 100%. People will then blame me for it not working. In software engineering, you should strive towards eliminating redundancy. 

Step 3 would mean that suddenly some foreign url would be exposed to the users, a technical detail which the users should not be bothered with.

The buttons in step 4 would need to be hardcoded by me. Similar redundancy concerns, and also if you install multiple add ons that possibly want to change that dialog, you'd be in trouble. E.g. you could have an entry to download in some custom download manager.

Maybe this seems like nit-pickery to you, but I don't want to offer my users (that includes myself) a worse experience only due to the web extensions move.

[1]: https://github.com/est31/openinbrowser/commit/cd2812ebc8037ac9c27f90dcd90960785aaeca47

Comment 8

[Caitlin Neiman [:caitmuenster]]

Hi est31! This has been added to the agenda for the April 25 WebExtensions Triage meeting. Would you be able to join us for a discussion about this bug? 

Call-in info and time: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Details_.26_How_to_Join

Agenda: https://docs.google.com/document/d/1WScwIH2D5tiL7vT4_lC44oFigR53xatWsUEwyjWvs7k/edit#

Comment 9

[est31]

Sure! I'll attend via IRC. Is that okay?

Comment 10

[Caitlin Neiman [:caitmuenster]]

Absolutely! We'll be in the #addons channel.

Comment 11

[Shane Caraveo (:mixedpuppy)]

I'm going to investigate the content handler issue further, I feel like it should be addressed or at a minimum really understand why we shouldn't use that mechanism.

Comment 12

[Shane Caraveo (:mixedpuppy)]

conversation with est31 on irc, noting my enhanced understanding of the request here.

- an unknown content type handler
- ability to be a part of the download dialog as an external content handler would (e.g. adobe reader in the dropdown for pdf downloads)

registerContentHandler requires a specific mimeType so does not handle this use case directly.  It also passes the download to the content handler directly rather than displaying the download dialog.

One problem I can see with this is that it would be possible to get into a situation where a download enters a black hole.

mixedpuppy: sure, but what’s the fallback?  if your addon doesn’t do anything with pdf, does that just fall into a black hole?
[12:10pm] 
mixedpuppy: as a user I select your addon, click the “always” checkbox, but if you don’t do anything with it, I’m kind of stuck (unless I figure out how to undo the always, but that’s potentially hard for users)
[12:10pm]

An option would be disallowing the "always" checkbox for such a catch-all content handler.

Further thoughts:

So basically, this is like a content handler, but there are internals that would certainly need work to make this possible from a simple API.

An option would be to use onDeterminingFilename, bug 1245652.  If the addon wants to handle that content type, maybe modify the mimeType so that a specific content handler gets initiated.

Comment 13

[Caitlin Neiman [:caitmuenster]]

Hi est31, this has been added to the agenda for the May 2 WebExtensions triage meeting. If you are available, we will keep a look out for you on IRC. :) 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1vf8AaW8tKKbMn4KhsqEYhrYqVTUGaERHQmzanEp2Cls/edit#

Comment 14

[Andy McKay]

Shane, in the notes from the last meeting, I think you were going to update this.

Comment 15

[Shane Caraveo (:mixedpuppy)]

Aside from the unhandled content handler, I still think a content handler system is the right way to address this. I also think we should do this, but I don't see it likely to happen for 57 given our current load.

Comment 16

[est31]

Thanks for the information!