308204 - null description in helper version info leaves Download Actions blank

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Peter Gasston]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

I attempted to change the Action for a file type (.torrent) from BitLord to
Azureus; the change was not accepted (BitLord remained the action) and when next
logging in all Actions were absent from the Download Actions field and all
buttons are greyed out. Problem has persisted after several reloads.

Reproducible: Always

Steps to Reproduce:
1. Open 'Options'
2. Choose Downloads > View & Edit Actions

Actual Results:  
No Actions are displayed

Expected Results:  
Displayed all file types and their associated actions

Comment 1

[bw456]

I can also confirm this is true on Windows 2000.  I believe it happens if you do
a  clean install of 1.0.6.  Specifically, I installed 1.0.6 on a W2K computer
that never used firefox before.  The file types are missing.  I have another W2K
computer that had firefox since 1.0.1, and is up-to-date (ie: running 1.0.6) and
the file types are there.

I would guess it has to do with the data in the profiles.  Perhaps 1.0.6 does
not create the initial file correctly??  I would also guess that if you create a
new profile in 1.0.6, the file types will be missing as well.

Comment 2

[bw456]

Attachment: Screenshot. File types are missing and buttons greyed out.

Comment 3

[Matth78]

I had the same bug with nighlty builds. Deleting the "mimeTypes.rdf" file in the
profile directory solved the problem.

Comment 4

[Kevin Brosnan]

If you go to about:config and toggle the pref javascript.options.showInConsole
to true, and then try to display the list, does the JavaScript Console show the
same error as in bug 309916 comment 0?

Comment 5

[Ria Klaassen (not reading all bugmail)]

I see the same when I start 1.0.7 in a new profile (so deleting mimeTypes.rdf
won't work for it is already brand-new). :)
In 1.5 I see them all.

Comment 6

[Mårten Svantesson]

I see the same problem in 1.5RC1
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Firefox/1.5)

(In reply to comment #4)
> If you go to about:config and toggle the pref javascript.options.showInConsole
> to true, and then try to display the list, does the JavaScript Console show the
> same error as in bug 309916 comment 0?

No.

Comment 7

[Ken Krebs]

Here's a writeup I did to reproduce the problem:

This has to do with the View & Edit Actions wndow in Tools -> Options -> Downloads -> View & Edit Actions

First, go there, verify that all your actions are there.  Should see stuff that is associated with your plugins and whatnot.

Second, visit this link: http://alt.binaries.nl/nzb/?id=36316873 and in the window that pops open change the 'Open with' actions to 'Other' from the dropdown menu and choose C:\Program Files\Windows Media Player\mplayer2.exe.  Make sure that you also select 'Do this automatically for files like this from now on.'

Third, click on OK and mplayer2.exe will open and you'll get an error.  Close it.  This was just a known, working example.  No worries.  Now go to back to Tools -> Options -> Downloads -> View & Edit Actions and you should notice they've all disappeared!  *Gasp*  No worries though.  Just click on the link above again and de-select 'Do this automatically for files like this from now on.'  Your actions will be back.

I first noticed this because I was setting certain files to load in my text editor which had C:\Apps\Metapad\Metapad.exe as its target.  The mplayer2.exe example above is just a known, working example to reproduce the error.  Pointing the file to Notepad in the Windows directory works as you'd normally expect it to for some reason.

Additionally, this error appears in the Javascript Console:

Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFileWin.getVersionInfoField]
Source file: chrome://browser/content/preferences/downloadactions.js
Line: 251

Comment 8

[timeless]

Attachment: this might fix it

Comment 9

[Adam Guthrie]

Ken, what version of Firefox were you using?

Comment 10

[Ken Krebs]

Adam, I totally forgot to add my build id in my posting.  Sorry!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051113 Firefox/1.5 - Build ID: 2005111303

Comment 11

[Kevin Brosnan]

*** Bug 313233 has been marked as a duplicate of this bug. ***

Comment 12

[Jesse Ruderman]

*** Bug 319021 has been marked as a duplicate of this bug. ***

Comment 13

[Joseph Cresencia]

I am currently experiencing this bug.

Did a total reformat of WinXP SP2.
Installed Firefox v1.5
Options->Downloads->"Download Actions"->View/Edit - shows all the download actions
Downloaded a torrent (normal naming convention - eg. file.torrent not file.avi.torrent)
Selected the program (Azureus.exe)
Selected Do this automatically.
Checked Options->Downloads->"Download Actions"->View/Edit - shows all BLANK

Uninstalled Firefox v1.5
Deleted all profiles under Document and Settings
Deleted the folder in Program Files
Deleted registry keys related to Mozilla
Installed latest trunk of Firefox (Deer Park Alpha 2) -> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051216 Firefox/1.6a1
Did the exact of the above - same results

NOT reproduceable in my laptop. But also has WinXPSP2 latest.
My laptop had Firefox since pre v1.0 (can't remember)
Installed OVER ON TOP of it for v1.0, v1.0.7, v1.5
Did the same steps above.
NOT reproducable (torrent extension was added correctly)

Comment 14

[Jonathan Haas]

Attachment: Screenshot in Firefox 1.6a1

I can reproduce this too, with new Firefox Trunk.

The window is empty although i've installed Flash, and set for .mp3-Files an application to open this (in download Dialog, "do this automatically for files from now on") 

This is bad, because now I can't download mp3's normally without editing mimetypes.rdf.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051220 Firefox/1.6a1 - Build ID: 2005122005
(Build-ID looks nice, doensn't it?)

Comment 15

[Henrik Gemal]

should we ask for r= and sr= on the patch?

Comment 16

[Ria Klaassen (not reading all bugmail)]

*** Bug 324155 has been marked as a duplicate of this bug. ***

Comment 17

[Wolfgang Haberl]

(In reply to comment #16)
> *** Bug 324155 has been marked as a duplicate of this bug. ***
> 

On my Computer I could reproduce that this happens if us set a programm with a blank in the filename as standard for some association. If you delete the blanks from the path in mimetypes.rdf, the actions will reappear in the window. Seems like one of the oldest mistakes in computer-history. Parsing blanks is the problem...

Comment 18

[Mårten Svantesson]

Hmm, I just realised that my earlier comment here was misplaced since this bug is marked "Windows XP" and I use Unix. Anyway, maybe others reading this will be helped by my finding that setting preference browser.download.hide_plugins_without_extensions to false made my Actions appear correctly.

Comment 19

[Henrik Gemal]

setting browser.download.hide_plugins_without_extensions to false also shows all of the actions on WinXP

Comment 20

[ck]

Experiencing the bug in 1.5.0.1 on WinXP SP2. 
[ Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ]

I was downloading torrents and firefox was asking for the program to open them. I was suprised it didn't pick it up automatically (since azureus was the registered program for .torrent files) so i clicked on 'do this automatically'. Checked on the actions later and were blank.

my setup: clean windows install. firefox the only mozilla application. using mouse gestures, noScript, viewSourceWith.

Comment 21

[Mike Connor [:mconnor]]

Comment on attachment 202963 [details] [diff] [review]
this might fix it

Seems like the wrong fix, based on subsequent comments about blanks in the filename

Comment 22

[Phil Ringnalda (:philor)]

Resummarizing: the thing with spaces in the path is something else (that I can't reproduce, or even imagine, since tens of millions of people have their external helpers installed in C:\Program Files): this bug is the result of having a helper that has version info (right click, properties, you see a "Version" tab) but has an empty description in that version info, which makes us choke trying to get it for the pretty name to display.

Steps to reproduce, take two:

1. Verify that you have actions listed in Options.
2. Install Azureus in the default C:\Program Files\Azureus.
3. Download a torrent, tell Firefox to open it with Azureus, and to remember to always do that.
4. Verify that you now have a blank list of Options.
5. Move Azureus to C:\Azureus, manually edit mimeTypes.rdf to point there, verify that you still have a blank list.
6. Patch downloadactions.js, and verify that you now have a list, though with an unsatisfactory "Open with (null)" for the Bittorent File action.

http://lxr.mozilla.org/mozilla/source/xpcom/io/nsILocalFileWin.idl#49 threatens that it will throw; we apparently need to catch it, and do something a little better than (null) for a fallback.

Comment 23

[Phil Ringnalda (:philor)]

Sigh. Assigned to nobody@, take ten million.

Comment 24

[Phil Ringnalda (:philor)]

Attachment: Fix

The try/catch works fine to keep things from exploding (at least from this particular cause), but the resulting "Open with (null)" isn't too pretty: this just lets it fall through to the filename that other platforms use. Installed Azureus with an unpatched build, got a blank list, opened that profile in a patched build, and the list is back, with it as "Open with Azureus.exe"

Comment 25

[Phil Ringnalda (:philor)]

Comment on attachment 214398 [details] [diff] [review]
Fix

I should really learn to read and understand comment 0, instead of fixing just the part that hits me. Patch that includes the copy of this code that handles *changing* actions once I finish enough test builds...

Comment 26

[Phil Ringnalda (:philor)]

Attachment: Fix, take 2

Now with extra bonus "actually fix the reported bug with changing, too" goodness.

Comment 27

[Mike Connor [:mconnor]]

Comment on attachment 214646 [details] [diff] [review]
Fix, take 2

r=me if you fix the "read the bundle name on OS X" comment to reflect the new reality

Comment 28

[Phil Ringnalda (:philor)]

But there is no new reality: that comment, translated, is "xxxben - this totally blows on OS X, we need to read the bundle name instead, because getting the filename fails uselessly for a bundle and we display 'Open With ' for every helper app." I'm not changing that (yet, here): from a post-processed Mac's view the code is completely unchanged.

I'll try to make a new reality by actually filing bugs on it, but I'd really rather have that comment remain, unchanged, because it's one of my markers for this bit of code, which is present not just in the tree in three places (Tbird, I'm coming for you!), but also in at least one pending patch that I need to track.

Comment 29

[4rvs19]

Attachment: A view of the empty "DL actions" window on Firefox 1.5.0.1

Comment 30

[4rvs19]

The problem is there in Firefox 1.5.0.1, persists after a total reinstall/reformat.

Used OS: WinXP w/ SP2 (build 2600)

Comment 31

[Phil Ringnalda (:philor)]

Attachment: Nits picked

mconnor cleared his "fix the comment" nit on IRC, I filed bug 332785 on replacing the comment with code, and this patch hopes to address gavin's nits well enough that he'll accept checkin blame on it :)

Comment 32

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 217706 [details] [diff] [review]
Nits picked

mozilla/browser/components/preferences/downloadactions.js 	1.10
mozilla/toolkit/mozapps/preferences/preferences.xml 	1.2

Comment 33

[olive]

I had the same problem with the empty list of file types in Firefox 1.5.0.2 and XP SP2

I've replaced the blanks in all installation paths of the  mimetypes.rdf (C:\Program Files\...) by an underscore : (C:\Program_Files\...) and it works now perfectly...

Comment 34

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/mozapps/preferences/preferences.xml 	1.1.8.1
mozilla/browser/components/preferences/downloadactions.js 	1.5.2.4

Comment 35

[Phil Ringnalda (:philor)]

*** Bug 342627 has been marked as a duplicate of this bug. ***

Comment 36

[bayswater]

Uhm - I have FF 2.0 and this is still a problem for me (and others: http://forums.mozillazine.org/viewtopic.php?t=348420&postdays=0&postorder=asc&postsperpage=15&start=75)

Comment 37

[bayswater]

I get this from the error console:

Error: uncaught exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.MIMEType]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://browser/content/preferences/downloadactions.js :: anonymous :: line 182"  data: no]

Comment 38

[War59312]

Same here, I still have this problem in FF 2.0. :(

Comment 39

[Phil Ringnalda (:philor)]

I don't know how you got the mistaken impression that this was the One True Bug About Anything That Makes Download Actions Blank, Always And Forever, but it's not. This bug was about one particular thing that used to make them blank, in versions before 2.0, and no longer does in 2.0 and after. If you still have a blank list in 2.0, then you have a bug which is not this bug, making this bug the wrong place to comment about your problem.

If removing spaces from helper app paths fixes your problem, then please file a new bug on that, and if you want it fixed, please try to figure out how your system is different from the tens of millions of other people who don't have a problem with helper apps in "C:\Program Files\".

If renaming the file mimeTypes.rdf in your profile so you get a new one created fixes your problem, then please file a new bug, and attach your old mimeTypes.rdf so someone can try to figure out what broke it.

If renaming mimeTypes.rdf only works until you set a particular program as a helper app, then please file a new bug, and attach the mimeTypes.rdf you get from just that particular program.

If instead you really really want to comment in this fixed bug, which fixed something other than your particular problem, please restrain yourself.

Comment 40

[bayswater]

@ #39 That is all well, but as u can see in the list above others have submitted this persisting problem as a new bug and had their submission marked as a dublicate...

Comment 41

[Phil Ringnalda (:philor)]

No, I cannot see that. I can see that bug 324155 was mistakenly marked as a duplicate, and then reopened; I can see that after this was fixed, bug 342627, reporting exactly this with exactly the same helper app, was marked as a duplicate; and I can see that none of the reporters of the early duplicates have reopened their bugs saying "that didn't fix it for me, apparently I have some other problem instead."

Your bug, though, is not this bug, and will not be marked as a duplicate of this bug, and this bug will not be reopened to deal with your different bug, and the only useful comment you can add to this bug which is not your bug is "I filed bug xxxxxx on the unrelated problem with nsIMIMEInfo.MIMEType returning not initialized."