1242292 - Helper dialog and download windows freeze when remote site reports content-type wrongly

Status: ASSIGNED

(SeaMonkey :: Download & File Handling, defect)

Description

[Dmitry Butskoy (:buc)]

Attachment: try file extension when content type hints nothing

Sometimes remote sites report content-types wrongly. In such a situation the file extension (if any) was the next chance.

Consider an example:

telnet bbr.ru 80
Trying 178.210.92.50...
Connected to bbr.ru.
Escape character is '^]'.
HEAD /docs/privileges-2.docx HTTP/1.0

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sun, 24 Jan 2016 22:04:21 GMT
Content-Type: application/vnd.openxmlformats

[snip]

Note the file extension ".docx", the standard content-type should be "application/vnd.openxmlformats-officedocument.wordprocessingml.document", but the site reports just "application/vnd.openxmlformats".

Since 2.35, SeaMonkey continue to show "helper chooser" dialog and offer the right application chosen (ie. "Libreoffise Writer" for the example above). But when the user hits this default choice, the generic error appears:
"The download cannot be saved because an unknown error occured" .

The problem is the changed behaviour of /mozilla/uriloader/exthandler/unix/nsMIMEInfoUnix.cpp:nsMIMEInfoUnix::LaunchDefaultWithFile() . Previously, it tries both "content-type" and "file extension", now the content type only. The correspond change is
http://hg.mozilla.org/releases/mozilla-aurora/diff/797672558e44/uriloader/exthandler/unix/nsMIMEInfoUnix.cpp#l116

This change is for removing no more needed gnomevfs stuff, but it seems that occasionally (?) the "else try file extension" part was removed too...

When I revert the change (in the needed part only, see attachment), the previous good behavior returns (as with seamonkey <= 2.33).


Note, that correspond code part is under "/mozilla" subdirectory, but the component is "SeaMonkey". The problem seems to occur with SeaMonkey only, not Firefox. It looks strange, since the code is the same.

For example: I've tested it with my personal build, which is official seamonkey-2.35 with mozilla/ subdir overwritten by official Firefox-38.5.2 mozilla-esr/ source. The SeaMonkey has the bug, but the system Firefox (with the same version, ie. the same source) has not.

Comment 1

[Dmitry Butskoy (:buc)]

Some interesting "good side-effect" of the patch above:

When a site reports "application/octet-stream" for, say, a pdf file, the unpatched variant has the helpers dialog which shows the proper type (ie. "PDF document"), but allows user either "save to disk" or "cancel". Interesting is that BOTH Firefox-38.5.2 and Seamonkey-2.39, 2.35 are affected (not SeaMonkey only as for initial issue).

With the patch applied, the "Document viewer (default)" appears in the helpers dialog (as it should be). Only thing which still blocked is "do this automatically...", but it seems due to "application/octet-stream" type etc.

Yet another thing with the "octet-stream" case is some kind of "instability" -- the unpatched SM-2.35 sometimes (about 10% of attempts) invokes the proper handler "automagically", and most cases (about 90%) allows to save to the disk only. Perhaps some thread issue(something does not have enough time before the helpers dialog appeared)?

Comment 2

[Rainer Bielefeld]

Version due to report!

@Dmitry Butskoy
Please contribute a step by step instruction how to reproduce the problem due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines>  (containing every key press and every mouse click, starting with "Launch SeaMonkey ...) how to reproduce the problem reliably.

Comment 3

[Dmitry Butskoy (:buc)]

SeaMonkey-2.39 is affected as well.

Comment 4

[Dmitry Butskoy (:buc)]

I've prepared a reliable local test (not to depend on any remote site).

To emulate a server side:

1) Download two attached files (a http headers -- a text "\r\n" file, and a simple test .docx file), just_a_headers.http and just_a_test.docx
2) Make sure "nc" program (/usr/bin/nc) is installed on your system
3) Run from cmdline:
  cat just_a_headers.http just_a_test.docx | nc -l 2222

On client side:
1) Start SeaMonkey
2) Type in urlbar:
  http://localhost:2222/just_a_test.docx
and hit enter.

Results: a dialog box appeared: "You have chosen to open" etc., which allows either "Open with Libreoffice Writer (default)", or "Save File", the first one is the default.

3) Type enter (ie. choose the default Libreoffice Writer variant).

Results: A progress bar appeared (with 100%) and then frozen, over the progressbar a box appeared with a message "The download cannot be saved because an unknown error occured"

(Then you have to manually close the frozen progressbar window).


Normally, after the hitting enter above, the progressbar should disappear, and the proper application should start.

Comment 5

[Dmitry Butskoy (:buc)]

Attachment: just_a_headers.http

just_a_headers.http, the text file (with '\r\n' endlining) containing the needed HTTP/1.1 server headers for the test.

Comment 6

[Dmitry Butskoy (:buc)]

Attachment: just_a_test.docx

just_a_test.docx, simple office openxml file for the test

Comment 7

[Rainer Bielefeld]

Version changed due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines#version>

Comment 8

[Dmitry Butskoy (:buc)]

Still here in 2.46

Could anybody confirm the test case above, as well as the Firefox-49 has no such an issue?

Comment 9

[Alex Henrie]

I ran the test case, but I didn't see any problems: The download manager correctly opened the file in LibreOffice. I have Firefox 51 on Arch Linux.

Comment 10

[Alex Henrie]

By the way, when you find a possible regression like this, please CC the author of the bisected commit. I would have liked to know about this bug report a year ago.

Comment 11

[Dmitry Butskoy (:buc)]

Sorry, but as i've mentioned above, the issue affects mostly SeaMonkey suite. Firefox (with the same code base as the correspond SeaMonkey version) seems not affected.

I would like somebody else (but me) will confirm that on the same code base FF has no issue, but SM has. Fe. Firefox-49 and Seamonkey-2.46 (latest released suite version).

On the other hand, considering the patch removing "gconf" stuff, it looks a bit strange that the same patch/commit removes some code not related to gconf. I thinked it was some kind of optimization for FF (since FF works with it), hence focused on SM developers for this.

Since you already run the test with FF, could you modify it for testing the issue from comment 1 ? (ie. when a site reports application/octet-stream for, say, pdf file). It seems gone as well with the patch attached...

Comment 12

[Frank-Rainer Grahl (:frg)]

could you try with a 2.52 or 2.53 nightly version. The backend was switched to jsdownloads. This still is not fully implemented and has some problems but if it works in Fx it should now work for SeaMonkey too.

Comment 13

[Dmitry Butskoy (:buc)]

Well, no more freeze with 2.53 beta1 .

The behaviour now is exactly as in Firefox-68 -- ie, it reports about "unknown content type" and ask user to choose the right application from a desktop menu (with a possibility to remember such a choise).

OTOH, it seems more friendly for end users to consider file extension (if any) in cases of "unknown or wrong content type", rather than cause them to choose "a right application" when they might know nothing about what to choose.

Anyway, I attach the proposed patch here for future desicions...

Comment 14

[Dmitry Butskoy (:buc)]

Attachment: try file extension when content type hints nothing, for SM 2.53 beta1

The patch against the latest SM 2.53 beta1.

Comment 15

[Ian Neal]

Trying either SM2.49.5, SM2.53.1 beta 1 or Firefox 71 on Fedora 30, I see no mention of "unknown content type" just "Word 2007 document (3.7kB)" in the dialog.
Where should I see it being reported?

Comment 16

[Dmitry Butskoy (:buc)]

It is "hard to catch", since once seen, the specs appear in ~/.config/mimeapps.list :)

To reproduce, use clear profile and make sure ~/.config/mimeapps.list is (temporary) removed.

Note, standard SM2.49.5 on Fedora 30 has the patch applied. Test with SM2.53.1 and any Firefox .

Comment 17

[Dmitry Butskoy (:buc)]

My tests was on CentOS-7

Comment 18

[Ian Neal]

Attachment: 1242292-mime-info-unix.patch

As far as I can see there is nothing wrong with the principle of the patch. I've attached a patch against current SM2.53.2

I've tried testing the unpatched application by removing ~/.config/mimeapps.list
tested that:
gio mime application/vnd.openxmlformats
produces:
No default applications for “application/vnd.openxmlformats”

With new profile, SM2.53.1 still picks up the correct LibreOffice Writer (default) and opens successfully.

Comment 19

[Ian Neal]

Maybe frg can test on another distro?

Comment 20

[Dmitry Butskoy (:buc)]

Well, test with "application/vnd.openxmlformats" was inspired by the actual case, but surely such a type might be included in some distro.

More correct test should use something like "application/foo-bar-nothing" instead.

Comment 21

[Frank-Rainer Grahl (:frg)]

Well I tried latest 2.53.2 with CentOS 7 and an older 2.53.1 with Ubuntu 18.04 but no unknown content type.

Comment 22

[Dmitry Butskoy (:buc)]

(In reply to Frank-Rainer Grahl (:frg) from comment #21)

Well I tried latest 2.53.2 with CentOS 7 and an older 2.53.1 with Ubuntu 18.04 but no unknown content type.

Even with "application/foo-bar-nothing" ??

Comment 23

[Frank-Rainer Grahl (:frg)]

Even with "application/foo-bar-nothing" ??

No dice on CentOS 7. Didn't change it in Ubuntu.