null description in helper version info leaves Download Actions blank

RESOLVED FIXED in Firefox 2 alpha2



14 years ago
12 years ago


(Reporter: p_gasston, Assigned: philor)



2.0 Branch
Firefox 2 alpha2
Windows XP

Firefox Tracking Flags

(Not tracked)



(6 attachments, 1 obsolete attachment)



14 years ago
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

14 years ago
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

14 years ago
Created attachment 196923 [details]
Screenshot.  File types are missing and buttons greyed out.

Comment 3

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

Comment 4

14 years ago
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?
Last Resolved: 14 years ago
Resolution: --- → INVALID


14 years ago
Resolution: INVALID → ---
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

13 years ago
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?


Comment 7

13 years ago
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: 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

13 years ago
Created attachment 202963 [details] [diff] [review]
this might fix it

Comment 9

13 years ago
Ken, what version of Firefox were you using?
Ever confirmed: true

Comment 10

13 years ago
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

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

Comment 12

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

Comment 13

13 years ago
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

13 years ago
Created attachment 206493 [details]
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

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


13 years ago
Attachment #202963 - Flags: review?(mconnor)
*** Bug 324155 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
(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...
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 to false made my Actions appear correctly.

Comment 19

13 years ago
setting to false also shows all of the actions on WinXP

Comment 20

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

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 on attachment 202963 [details] [diff] [review]
this might fix it

Seems like the wrong fix, based on subsequent comments about blanks in the filename
Attachment #202963 - Flags: review?(mconnor) → review-

Comment 22

13 years ago
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. threatens that it will throw; we apparently need to catch it, and do something a little better than (null) for a fallback.
Summary: Download Actions is blank; no Actions or File Types displayed → null description in helper version info leaves Download Actions blank

Comment 23

13 years ago
Sigh. Assigned to nobody@, take ten million.
Assignee: nobody → philringnalda

Comment 24

13 years ago
Created attachment 214398 [details] [diff] [review]

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"
Attachment #214398 - Flags: review?(mconnor)

Comment 25

13 years ago
Comment on attachment 214398 [details] [diff] [review]

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...
Attachment #214398 - Attachment is obsolete: true
Attachment #214398 - Flags: review?(mconnor)

Comment 26

13 years ago
Created attachment 214646 [details] [diff] [review]
Fix, take 2

Now with extra bonus "actually fix the reported bug with changing, too" goodness.
Attachment #214646 - Flags: review?(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
Attachment #214646 - Flags: review?(mconnor) → review+

Comment 28

13 years ago
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.
Whiteboard: [checkin needed]

Comment 29

13 years ago
Created attachment 216072 [details]
A view of the empty "DL actions" window on Firefox

Comment 30

13 years ago
The problem is there in Firefox, persists after a total reinstall/reformat.

Used OS: WinXP w/ SP2 (build 2600)

Comment 31

13 years ago
Created attachment 217706 [details] [diff] [review]
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 :)
Attachment #217706 - Flags: review?(
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
Attachment #217706 - Flags: review?( → approval-branch-1.8.1?(mconnor)
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Target Milestone: --- → Firefox 2 alpha2
Version: unspecified → 2.0 Branch
Attachment #217706 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+

Comment 33

13 years ago
I had the same problem with the empty list of file types in Firefox 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...
Keywords: fixed1.8.1

Comment 35

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

Comment 36

12 years ago
Uhm - I have FF 2.0 and this is still a problem for me (and others:

Comment 37

12 years ago
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

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

Comment 39

12 years ago
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

12 years ago
@ #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

12 years ago
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."
You need to log in before you can comment on or make changes to this bug.