Download dialog shown for tasvideos.org

[Sintendo]

I think the issue may be similar to #31, but I figured I'd open another issue to be sure. The response contains no Content-Type header for http://tasvideos.org (other parts of the site luckily do).

[Rob--W]

Yes this is the same issue. Perhaps I should not show the dialog by default when the type is missing.

[nyanpasu64]

I'm still getting this issue on 2.6 (related #33 was closed). It seems "open in Firefox, do automatically" produces expected behavior (tasvideos.org loads normally).

• Turns out doing the above has again highlighted "open in Firefox" when opening binary files, because #40 and 3cad66c remember the last option, instead of picking "save file" (default Firefox behavior on binary files) as the default behavior. (unimportant question, why is default Firefox behavior "open in Firefox" for tasvideos but "save file" elsewhere?)

If, upon encountering an empty MIME, Firefox always tries to open in browser (instead of downloading), I think there's no need for this extension to intercept the request (it's safe to hard-code "open in Firefox, do automatically").

• Looking at stackoverflow.com/How do I force files to open in the browser instead of downloading (PDF)? it seems that the "download file" flag is part of the Content-Disposition header, distinct from the MIME type.
• So if you force Firefox native behavior for empty MIME, this extension fails if Firefox guesses a binary MIME, or if Content-Disposition: attachment.
  • You could intercept Content-Disposition: attachment even for empty MIME.

[Rob--W]

If, upon encountering an empty MIME, Firefox always tries to open in browser (instead of downloading), I think there's no need for this extension to intercept the request (it's safe to hard-code "open in Firefox, do automatically").

When Firefox encounters an empty MIME, it will perform MIME-sniffing and potentially result in a Save As/Open With dialog.

In the past versions there had been a bug where the extension immediately defaults to the default behavior when the Content-Type is empty (04e4f84a30f5f42188edc03d22ae2e2c84e9c10f). I have fixed this, and now the extension will display a dialog if the Content-Type header is set, and to an empty header.

@jimbo1qaz Do you have any suggestions / feature requests before I publish an update?

[nyanpasu64]

(unrelated) On Kubuntu 18.04, I was getting a bug where pressing "Save File" popped up Firefox's native save dialog. I can't reproduce on Firefox Dev + Windows 10 at the moment.

[Rob--W]

@jimbo1qaz That sounds like a different issue, and I think that I managed to reproduce it. I have published a new update with new instructions to avoid the native save dialog. Update to 2.7 and see the options page. Please let me know whether the instructions are clear and whether it addresses the issue.

EDIT: The change is 2c09e4504d7c99e8f415896dc78597b8796d5135

[nyanpasu64]

How do I test OP's bugfix? Did you not push it yet, do you have a debug build for me to test?

Maybe you should automatically tell the user to "prevent double saving", when your addon is first installed. I did so on Windows, but forgot when syncing my addon list to Linux.

(i really think webextensions are seriously crippled, but at least they're more stable than regular addons... Though I still got a corrupted tab list recently)

[Rob--W]

@jimbo1qaz "OPs bugfix? You mean the referenced commit? I already released a new version (2.7) with that change.

Maybe you should automatically tell the user to "prevent double saving", when your addon is first installed. I did so on Windows, but forgot when syncing my addon list to Linux.

I considered doing that, but did not want to bug the user when the add-on is auto-installed. To avoid that issue, I considered adding a message to the Open in Browser dialog, when the Save option is selected. However I didn't get to that yet and it's not a priority.

[nyanpasu64]

I'm on 2.7, cleared my "Your saved MIME actions", and tasvideos.org still pops up a save dialog.

Firefox 62.0b10 (64-bit)

[Rob--W]

@jimbo1qaz My patch did not fix the original issue here (hence the issue is still open). I only fixed the (unrelated) issue that you reported in https://github.com/Rob--W/open-in-browser/issues/32#issuecomment-407924170

The issue in the OP is caused by the server not replying with any Content-Type. The effect of that is that Firefox will use content sniffing, and potentially show a Save As dialog. Since it is not possible to determine in advance what Firefox will do, I always show the Open in Browser dialog in this case.

I'm considering to add an option (default off or on?) to disable the dialog for empty MIME types, with an exception for common inlineable types such as PDF files.

(i.e modify the logic around this point:) https://github.com/Rob--W/open-in-browser/blob/b1153d8cea37ee05b76b30ecbf2519746acea693/extension/background.js#L95-L98