1040005 - Open with dialog: Empty menu item

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[kernp25]

If you get the open with dialog, the menu item will be empty.

If you set pdf files to always ask, and then open a pdf file, the menu item will be empty. (the menu item from open with).

See the picture.

Comment 1

[kernp25]

Attachment: openwith.PNG

Comment 2

[kernp25]

Attachment: openwith2.PNG

Comment 3

[kernp25]

This bug has something to do with this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=480242

Because now the preferredAction is changing to alwaysAsk.

http://dxr.mozilla.org/mozilla-central/source/browser/components/preferences/applications.js#1679

Comment 4

[kernp25]

I have nightly 33.0a1 (2014-07-16)

Comment 5

[kernp25]

I have created an addon to test it myself.
The preferredAction is useHelperApp but it should be useSystemDefault.
Note: It can be solved, by opening the pdf file with the application (because preferredAction is changing to useSystemDefault)

Comment 6

[kernp25]

But, if i changing again the action for e.g. pdf then this bug will occur again.

Comment 7

[kernp25]

Note: This does not always happen for pdf files.
Because the preferredAction is sometimes useSystemDefault not useHelperApp.

e.g. https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=41266

Content-Type:	application/unknown
Content-Disposition:	attachment;filename="Volume 4_SPEC.pdf"

Comment 8

[Catalin Varga [QA][:VarCat]]

I didn't manage to reproduce this with FF 33.0b2 nor FF 35 latest build can you please try again with the latest Beta or Nightly build using a new profile.

Comment 9

[Gingerbread Man]

Attachment: LinuxMint_OpenWith.png

I ran into this bug in Firefox 36.0.4 under Linux Mint KDE 17.1, which came with KTorrent as the application associated with .torrent files.

Steps to reproduce:
1. Under Preferences -> Applications, set the action for .torrent files to “Always ask”.
2. https://kickass.to/mozilla-firefox-6-0-1-beta2-full-win-32-amp-64-bit-reddragon-t5671318.html
3. Near the top left, click the “DOWNLOAD TORRENT” button.

Actual results:
The drop-down menu next to “Open with” is very short, and it's blank, with no menu item selected by default.

Expected results:
The drop-down menu next to “Open with” should have the application associated with that particular file type selected by default.

For the above, the server sends Content-Type: application/octet-stream. I wasn't able to reproduce the issue when the header is Content-Type: application/x-bittorrent, like the following. N.B.: in this case, “DOWNLOAD TORRENT” is a fake link. Be sure to click the “Linux Ubuntu 10.04 LTS Desktop Edition” link instead.
http://rarbg.com/torrent/hzgcrxle2ibaws153qv4dk69ony8jpum7tfuf6a4pqnri2eoh1wjzty5vcmbx8g3sk79dl

I also wasn't able to reproduce either of the above under Windows 7. However, I do recall previously running into the bug under that operating system. I'll post another comment if I come across it again at some point.

I wasn't able to reproduce comment 7 either under Windows 7 or Linux Mint KDE 17.1.

Comment 10

[Gingerbread Man]

Attachment: Windows7_LinuxMint_OpenWith.png

I managed to find a situation that triggers this on Windows 7 as well as Linux Mint KDE 17.1. I tested both Firefox 37 and the latest Nightly, each with a separate, brand new profile.

1. Start Firefox in a brand new profile.
2. Click the following link. When asked what to do with the ZIP file, choose to save it, check “Do this automatically…” then allow the download to complete.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/jsshell-win32.zip
3. Open up Options/Preferences → Applications and set ZIP files to “Always ask”.
4. Click the link at step 2 again.

Comment 12

[Gingerbread Man]

Gijs, this report has lingered for quite some time. Any idea what's causing this issue? Also, doesn't it belong in File Handling rather than Download Manager?

Comment 13

[:Gijs (he/him)]

(In reply to Gingerbread Man from comment #12)
> Gijs, this report has lingered for quite some time.

I won't be able to look at this today. I might have time later this week.

> Any idea what's causing this issue?

Not offhand. Is it a regression?

> Also, doesn't it belong in File Handling rather than Download
> Manager?

Probably/maybe. It's not entirely clear whether the info in the relevant db/rdf is wrong, or if it's just misinterpreted by the component reading it, or by the helper app dialog which then produces bogus UI. Could be anywhere at this point.

Comment 14

[Gingerbread Man]

(In reply to :Gijs Kruitbosch from comment #13)
> I won't be able to look at this today. I might have time later this week.

Thank you in advance.

> Is it a regression?

Yes. With the STR at comment 10, these are my results:

2014-06-23: the last good build.
https://hg.mozilla.org/mozilla-central/rev/366b5c0c02d3

2014-06-24 to 2014-07-07: it's impossible to switch from “Save file” to “Always ask”. The change reverts after clicking another item in the Applications pane or after closing the Options tab.
https://hg.mozilla.org/mozilla-central/rev/e86b84998b18
https://hg.mozilla.org/mozilla-central/rev/1dc6b294800d

2014-07-08: the setting can once again be changed, and the issue described in this report is reproducible.
https://hg.mozilla.org/mozilla-central/rev/c45f6e6d6005

Comment 15

[:Gijs (he/him)]

(In reply to Gingerbread Man from comment #14)
> (In reply to :Gijs Kruitbosch from comment #13)
> > I won't be able to look at this today. I might have time later this week.
> 
> Thank you in advance.
> 
> > Is it a regression?
> 
> Yes. With the STR at comment 10, these are my results:
> 
> 2014-06-23: the last good build.
> https://hg.mozilla.org/mozilla-central/rev/366b5c0c02d3
> 
> 2014-06-24 to 2014-07-07: it's impossible to switch from “Save file” to
> “Always ask”. The change reverts after clicking another item in the
> Applications pane or after closing the Options tab.
> https://hg.mozilla.org/mozilla-central/rev/e86b84998b18

This smells like bug 480242 which was fixed by the bugreporter of this bug....

> https://hg.mozilla.org/mozilla-central/rev/1dc6b294800d
> 
> 2014-07-08: the setting can once again be changed, and the issue described
> in this report is reproducible.
> https://hg.mozilla.org/mozilla-central/rev/c45f6e6d6005

which would correspond to bug 1034043 where the typo introduced in bug 480242 was fixed.

kernp25, any chance you can investigate exactly what's wrong here yourself? :-)

Comment 16

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1040005 - fix nsHelperAppDlg.js to cope with always ask in combination with a preferred helper app, r?mconley

Bug 1040005 - fix nsHelperAppDlg.js to cope with always ask in combination with a preferred helper app, r?mconley

Comment 17

[:Gijs (he/him)]

remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a03360e8971

Comment 18

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #17)
> remote:  
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a03360e8971

None of the tests here seem to actually indicate something wrong with this patch. :-)

Comment 19

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8688506 [details]
MozReview Request: Bug 1040005 - fix nsHelperAppDlg.js to cope with always ask in combination with a preferred helper app, r?mconley

https://reviewboard.mozilla.org/r/25333/#review22957

Thanks Gijs. A test for this would be brilliant, if you have the time.

::: toolkit/mozapps/downloads/nsHelperAppDlg.js
(Diff revision 1)
> -    var useDefault = this.dialogElement("useSystemDefault");

Gross - this element never existed. I can't find traces of an element with "useSystemDefault" in unknownContentType.xul going back to, well, hg@0.

Comment 20

[:Gijs (he/him)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #19)
> Comment on attachment 8688506 [details]
> MozReview Request: Bug 1040005 - fix nsHelperAppDlg.js to cope with always
> ask in combination with a preferred helper app, r?mconley
> 
> https://reviewboard.mozilla.org/r/25333/#review22957
> 
> Thanks Gijs. A test for this would be brilliant, if you have the time.

I don't know about time, but I filed a followup anyway (bug 1226120). I don't think we have a lot of (or even any??) automated tests of this dialog. Probably a good idea to change that.

Comment 21

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/3a6d7dcaaae5

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3a6d7dcaaae5