1659008 - Setting binary/octet-stream PDF files to open in Firefox causes a blank entry in application handlers

Status: ASSIGNED

(Firefox :: File Handling, defect, P1)

Description

[Mike Kaply [:mkaply]]

Attachment: Screenshot of blank entry.

If you visit:

https://smallpdf.com/shared#pt=02fdd17c-5a41-4a2c-a381-e094422dca8d

Click the link, make sure open in Firefox is checked and check the box that says "Do this for files like this from now on" , you end up with a blank entry in preferences (see attachment).

Also, it keeps asking you even though you said don't ask again.

Comment 1

[Mike Kaply [:mkaply]]

You also get a download notification in nightly when you do this as well, even though it's opening in Firefox?

Comment 2

[Mathew Hodson]

Did you mean to mark this as regressed by bug 773942?

Comment 3

[Mike Kaply [:mkaply]]

Yes, thanks.

Comment 4

[:Gijs (he/him)]

Bizarrely, I can't reproduce on my main profile, only on clean ones. It seems to be related to the server passing a bogus-but-not-recognized-bogus content type (it uses binary/octet-stream, as opposed to application/octet-stream - or, more reasonably, application/pdf ).

Also, it keeps asking you even though you said don't ask again.

This is bug 453455, see specifically comment #22 for why people have been reluctant to change this in the past.

You also get a download notification in nightly when you do this as well, even though it's opening in Firefox?

Yeah, this is expected. Maybe it feels odd for small files, but if this was a 10mb pdf and you had a slow internet connection, I'm pretty sure you'd want some evidence of progress.

The web site has explicitly picked "download" behaviour here and that's why we don't immediately open in a tab (and handle loading progress inside pdfjs) like we do for inline-served PDFs. See also lengthy discussion in e.g. bug 1655974 .

I get that this is perhaps not the most intuitive behaviour from the user's perspective in some cases, but getting the most intuitive behaviour from a user's perspective is hard given our current download flow and people's wide ranges of expectations. See also bug 1653807 etc. etc.

Comment 5

[Mike Kaply [:mkaply]]

This is bug 453455, see specifically comment #22 for why people have been reluctant to change this in the past.

Considering the number of dupes, we really should make some choice. Does our new support for attachment PDF files make this even worse? As in you can't tell Firefox to always open PDFs in Firefox? Or is this bug a different problem because the file isn't served as application/pdf, so we are making the decision based on the extension?

Comment 6

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #5)

This is bug 453455, see specifically comment #22 for why people have been reluctant to change this in the past.

Considering the number of dupes, we really should make some choice.

"Why don't you just".

The choice that's in the process of being made is "get rid of the confusing dialog, just always download things". But that entails a bunch of other work (like making sure that "open this file immediately" is easy to access, and that downloads don't get lost) that is not trivial, so it hasn't happened yet.

Does our new support for attachment PDF files make this even worse? As in you can't tell Firefox to always open PDFs in Firefox? Or is this bug a different problem because the file isn't served as application/pdf, so we are making the decision based on the extension?

I don't understand the question. If the server sends content-disposition: attachment, unless the user has said "always save this file type to disk", we show the dialog. The dialog now has a new option that it didn't have before. How would that make anything worse?

Comment 7

[Mike Kaply [:mkaply]]

The dialog now has a new option that it didn't have before. How would that make anything worse?

Because folks might more prone tell Firefox to "always do this" for PDF files and it doesn't work?

unless the user has said "always save this file type to disk", we show the dialog.

I thought we just established that "always save this file type to disk" doesn't work in this case...

Comment 8

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #7)

unless the user has said "always save this file type to disk", we show the dialog.

I thought we just established that "always save this file type to disk" doesn't work in this case...

It doesn't work if you select "open with helper", because that risks dataloss if the helper doesn't let you save the file. saving to disk doesn't have that risk so it will happen "even" for content-disposition:attachment files.

Comment 9

[Mike Kaply [:mkaply]]

It doesn't work if you select "open with helper", because that risks dataloss if the helper doesn't let you save the file. saving to disk doesn't have that risk so it will happen "even" for content-disposition:attachment files.

But it also doesn't work with "Open in Firefox" for PDF files. Is that because we consider that a helper?

Comment 10

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #9)

It doesn't work if you select "open with helper", because that risks dataloss if the helper doesn't let you save the file. saving to disk doesn't have that risk so it will happen "even" for content-disposition:attachment files.

But it also doesn't work with "Open in Firefox" for PDF files. Is that because we consider that a helper?

Yes. We download to the temp dir and the file is deleted when Firefox exits (on Windows and Linux, it's different on mac).

Comment 11

[:Gijs (he/him)]

Attachment: Bug 1659008 - do not store user preferences for binary/octet-stream mimetypes, r?jaws

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d7d16d30097d
do not store user preferences for binary/octet-stream mimetypes, r=jaws

Comment 13

[Razvan Maries]

Backed out for perma failure.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=L0Wtqi7DS1qb8zl28OHc0w.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=d7d16d30097d5a101eae87aeb0985daf3548c994

Log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313596759&repo=autoland&lineNumber=6433

Backout: https://hg.mozilla.org/integration/autoland/rev/c105f961424c3a56aafccc82205d797d012f3b64

Comment 14

[:Gijs (he/him)]

I think this is one of those rare cases where a test (even if somewhat inadvertently) points out a real problem.

The test is failing because it tries to select a different external handler app for a PDF served with various different mimetypes, and then checks that that choice is persisted. It fails on Windows because there (and only there) there is more than 1 option available, so the test actually works, and after my changes we no longer persist anything for the PDF served with binary/octet-stream.

The "right" fix is probably for the dialog to look up mime info and store mime info for a meaningful mimetype, if one is available, for files served with application/octet-stream or binary/octet-stream. But that's a bigger change than I think we can land in soft-freeze.

Jared, does that seem right to you?

The other subtlety here is as follows... the dialog code uses MIMEInfo which is a readonly property of mLauncher, ie an nsIHelperAppLauncher. We will treat application/octet-stream as a download in various places (though I recently made an exception for PDFs, which then doesn't cover binary/octet-stream, I believe...), and if we change the mime info object prior to the app launcher object, that might affect whether we even show the dialog, which I don't think we want to do. But if the user configures e.g. application/pdf to always save to disk (without asking), we should do that for application/octet-stream PDFs, too...

Comment 15

[:Gijs (he/him)]

Per discussion with Jared, going to see if there's a wallpaper-y alternative we can use here instead, as the can of worms from comment #14 does not look particularly appetizing.

Comment 16

[:Gijs (he/him)]

Haha, except I've just realized that we do really dumb things with these mimetypes right now, because the handler database is keyed on mimetypes and extensions are an afterthought. The optimism of 90s *nix users, I guess. :-|

If you save octet-stream things with different extensions, we just gradually collect extensions into the list of associated extensions, but display it in the list in preferences as whatever thing first got saved. So if you handle PDFs internally ("Open with Firefox") and save that, and then try to download a .txt file that is served with binary/octet-stream, and pick, say, "save to disk", and save that, now you'll have an entry in the list that says "Portable document format (binary/octet-stream) -- Save to disk", and that will apply to txt files served with binary/octet-stream. Because of course.

So I don't like wallpapering this anymore. I think not saving these associations into octet-stream mimetypes (and removing them if previously saved) is the Right Thing and we need to do it. There's some obscure usecase we might affect here (ie handling of files with extension "foo" differing based on whether the mimetype is application/x-foo or application/octet-stream) but I think we should not care about that as it's much too niche and the potential for foot-shooting is too great.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:Gijs, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 18

[Luca M.]

+1 in organizations we need to solve this problem.

Comment 19

[Mike Kaply [:mkaply]]

Apparently application/x-download is a thing as well.

Just did a download and ended up with this in my handlers.json

	"application/x-download": {
		"action": 3,
		"extensions": ["pdf"]
	}

and a blank entry in preferences.

Comment 20

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #19)

Apparently application/x-download is a thing as well.

Just did a download and ended up with this in my handlers.json

  "application/x-download": {
  	"action": 3,
  	"extensions": ["pdf"]
  }

and a blank entry in preferences.

I mean, not just the action of opening the link. Do you have a testcase? What options did you select in the dialog?

Comment 21

[Mike Kaply [:mkaply]]

Go to:
https://webpagetopdf.com/
and put in any URL.
After it processes, you'll get a dialog that defaults to "open with nightly"
Check the "Do this automatically" checkbox. Click OK.
The PDF will open in a new tab. Go back to the page, and click "Click here to download".
You'll get the helper app dialog instead of having it open again.
about:preferences shows a blank entry for Portable Document Format (PDF) (application/x-download)

I did some testing with Google docs as well, and even though they appear to be using the correct mime type when you open a PDF from Google docs:

HTTP/2 200 OK
content-type: application/pdf
content-disposition: attachment; filename="filename.pdf"

The "Do this automatically" checkbox still doesn't stay checked and in this case, no new entry is added to application preferences.

Comment 22

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #21)

The "Do this automatically" checkbox still doesn't stay checked and in this case, no new entry is added to application preferences.

This is well known and is bug 453455.

Comment 23

[:Gijs (he/him)]

Still hope to eventually have time to re-investigate the blank entry stuff, but it's all a rats nest, see comment #16 .

Comment 24

[Slot88]

https://rtprrqslot188.live/
https://elearning.unsulbar.ac.id/courses/CASINOONLINETERPERCAYA/document/index.html
https://webfinary.com/
https://linksyu.net/
https://www.shabelle.net/
https://157.230.47.109/
https://situsslotterpercayaslot88.blogspot.com/2023/04/slot88-situs-slot-gacor-hari-ini-rrq.html
https://bonanza168.info/
https://affiliatecrossing.com/
https://kiwbet.net
https://profile.fredhutch.org/slot-gacor/
https://playbet88slot.com
https://walterzorn.com
https://rrqslot188.net
DAFTAR SITUS SLOT GACOR TERPERCAYA RRQSLOT188