57.49 KB, image/jpeg
754 bytes, patch
|Details | Diff | Splinter Review|
21.43 KB, image/png
2.98 KB, patch
|Details | Diff | Splinter Review|
19.18 KB, image/jpeg
3.07 KB, patch
|Details | Diff | Splinter Review|
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
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.
I had the same bug with nighlty builds. Deleting the "mimeTypes.rdf" file in the profile directory solved the problem.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 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.
Ken, what version of Firefox were you using?
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
*** Bug 313233 has been marked as a duplicate of this bug. ***
*** Bug 319021 has been marked as a duplicate of this bug. ***
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)
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?)
should we ask for r= and sr= on the patch?
*** Bug 324155 has been marked as a duplicate of this bug. ***
(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 browser.download.hide_plugins_without_extensions to false made my Actions appear correctly.
setting browser.download.hide_plugins_without_extensions to false also shows all of the actions on WinXP
Experiencing the bug in 220.127.116.11 on WinXP SP2. [ Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:18.104.22.168) Gecko/20060111 Firefox/22.214.171.124 ] 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-
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.
Status: NEW → ASSIGNED
Summary: Download Actions is blank; no Actions or File Types displayed → null description in helper version info leaves Download Actions blank
Sigh. Assigned to nobody@, take ten million.
Assignee: nobody → philringnalda
Status: ASSIGNED → NEW
Created attachment 214398 [details] [diff] [review] 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 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...
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+
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]
The problem is there in Firefox 126.96.36.199, persists after a total reinstall/reformat. Used OS: WinXP w/ SP2 (build 2600)
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?(gavin.sharp)
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?(gavin.sharp) → approval-branch-1.8.1?(mconnor)
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 13 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+
I had the same problem with the empty list of file types in Firefox 188.8.131.52 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...
mozilla/toolkit/mozapps/preferences/preferences.xml 184.108.40.206 mozilla/browser/components/preferences/downloadactions.js 220.127.116.11
*** Bug 342627 has been marked as a duplicate of this bug. ***
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)
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]
Same here, I still have this problem in FF 2.0. :(
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.
@ #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...
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.