Closed Bug 359630 Opened 18 years ago Closed 5 years ago

Windows cannot find 'SHORTCUT' when clicking link from desktop after crash

Categories

(Firefox :: Shell Integration, defect)

Product:
Firefox
Component:
Shell Integration
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: smichae, Unassigned)

References

Details

(Whiteboard: [notacrash])

Attachments

(1 file)

Error Message
43.65 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 With 'restore old tabs after crash' being used, crashing Firefox, then opening a URL shortcut will result in a Windows error message. Reproducible: Always Steps to Reproduce: (Pre-condition for reproducing error) 1. Drag and drop a URL's icon from Firefox to the Desktop to create a shortcut to that webpage. 2. Ensure Firefox is your default browser. (Actual reproduction of error) 1. Crash Firefox (Specific approach: Have a webpage with only a JavaScript alert, then use Windows Task Manager to kill the Firefox process.) 2. Open the URL shortcut that you created in the pre-condition step. 3. Windows will create the error message: "Windows cannot find 'http://www.google.com/firefox'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search." Actual Results: Windows will create the error message: "Windows cannot find 'http://www.google.com/firefox'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search." Expected Results: Windows should not create the error message. The OS doesn't seem to be getting the "OK" from Firefox before the 'Restore old tabs after crash' dialog is displayed.
This is, for me, still a consistent bug in Windows. It also occurs when Firefox reports updates to extensions on startup (eg the update dialog appears). My uneducated guess is that if the first window Firefox opens is not the main window, the DDE conversation gets fired to the wrong window and the window doesn't handle it, so Windows thinks that the program cannot handle the request (although firefox has a fine time just parsing the command line). Hope this helps.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4 Reproduced. To "crash" Firefox, I opened up the print dialog box (File->Print) and then killed Firefox from the Task Manager. Windows reports the error given by the reporter, despite the fact that Firefox actually opens up the page specified by the shortcut.
Confirmed using Firefox 2.0.0.4 on Windows XP SP 2. Also confirmed using the latest trunk nightly on Windows XP SP 2. Full steps to reproduce: 1. Open Firefox 2. Set Firefox as the default browser 3. Drag the favicon/site icon to the desktop to create a shortcut to the current site. 4. Select File -> Print 5. Press ctrl-alt-delete 6. Select Firefox from the Applications tab and press the "End Task" button 7. Press the "End Now" button on the dialog that appears 8. Double click the shortcut you created in step 3 At this point, two dialogs appear for me: 1. The "Restore Previous Session" dialog 2. A dialog with the following title/content: http://www.mozilla.org/ ( x ) Windows cannot find 'http://www.mozilla.org'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search. Note that once you dismiss the dialog and click either the "restore" or "start new" session buttons, the page will display properly. See also bug 246078 which is marked FIXED and bug 137363 which is probably the equivalent SeaMonkey bug, if that product needs its own bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 389502
I can confirm this is happening on 3 of my Win XP Pro machines. Happened after the update to v2.0.0.2 or .3 and has continued to plague my machines. Clicking on any http or related URL in, for example, e-mail, results in the same Windows error message as quoted above. Firefox does in fact open the URL, but once finished and Firefox is closed, closing the error message window (with the "X" radio button) that is lurking in the background behind the browser windows will reopen Firefox to the same URL. I do not believe this is related to a crash problem; Firefox very rarely "crashes". It simply does not behave properly when being spoken to by DDE. Switching the default browser back to IE eliminates the problem. Unacceptable. I don't want IE to be default for anything. I am presently running Firefox 2.0.0.6.
Just to confirm - the problem is STILL occurring in v2.0.0.9 on WinXP (Pro, SP2). The workaround posted at http://kb.mozillazine.org/Windows_error_opening_Internet_shortcut_or_local_HTML_file_-_Firefox works fine, but has to be repeated every time Firefox installs an update!?
(In reply to comment #7) > Just to confirm - the problem is STILL occurring in v2.0.0.9 on WinXP (Pro, > SP2). Same here. >The workaround posted at >http://kb.mozillazine.org/Windows_error_opening_Internet_shortcut_or_local_HTML_file_-_Firefox > works fine, but has to be repeated every time Firefox installs an update!? So it would appear. It's been the case since the 2.0.0.2 >> 2.0.0.3 update. (Or possibly even before. Though I'm not a coder, it would seem that this would be an easy one to track down and repair. (?) All the best, Marc
This bug is a dupe of so many of the same bugs it is getting crazy. I has happened for me ever since 2.0.0.0 (maybe before). It is most definitely NOT fixed.... Stop closing the bugs as "verified fixed" Every other dupe (this one included) of this bug suggests deleting the ddeexec keys from the registry entries below, but this is only a temporary fix. After your Firefox installation "auto upgrades" it breaks the registry keys again! The problem is recreated when the upgrade adds the ddeexec keys with the (default) string value of "%1",,0,0,,,, To fix (temporary, will break again on update or reinstall), remove the ddeexec entries from the following keys: HKCR\HTTP\shell\open HKCR\htmlfile\shell\open HKCR\htmlfile\shell\opennew HKCR\ftp\shell\open HKCR\gopher\shell\open HKCR\https\shell\open HKCR\FirefoxHTML\shell\open HKCR\FirefoxURL\shell\open (May be more keys, but this is all I could find so far) This is a verified issue with both Windows XP and Windows Vista (all versions)
Brian: Please refrain from cutting and pasting the same comment in various OS integration bugs when they don't apply to the bug in question. This bug has not been duped and has not been verified fixed. If you think it has something to do with keys than please focus your comment around that issue. Thanks. (In reply to comment #9) > This bug is a dupe of so many of the same bugs it is getting crazy. I has > happened for me ever since 2.0.0.0 (maybe before). > > It is most definitely NOT fixed.... Stop closing the bugs as "verified fixed" > > Every other dupe (this one included) of this bug suggests deleting the ddeexec > keys from the registry entries below, but this is only a temporary fix. After > your Firefox installation "auto upgrades" it breaks the registry keys again! > > The problem is recreated when the upgrade adds the ddeexec keys with the > (default) string value of "%1",,0,0,,,, > > To fix (temporary, will break again on update or reinstall), remove the ddeexec > entries from the following keys: > > HKCR\HTTP\shell\open > HKCR\htmlfile\shell\open > HKCR\htmlfile\shell\opennew > HKCR\ftp\shell\open > HKCR\gopher\shell\open > HKCR\https\shell\open > HKCR\FirefoxHTML\shell\open > HKCR\FirefoxURL\shell\open > > (May be more keys, but this is all I could find so far) > > This is a verified issue with both Windows XP and Windows Vista (all versions) >
?? Bug duped in comment 3, 4, and 5 All other "dupes" of this bug keep getting marked fixed, but the issue obviously still exists (hence this "new" bug) I believe it is the same duped bug that I have posted that comment on before, due to comments 6, 7, and 8. I am really getting tired of all the bugs this issue pertains to just being "fixed" and then closed. Just to find out I have the same problem after the next update. It is quite obvious that the ["%1",,0,0,,,,] string is not correct or valid for the ddeexec variable. This issue is not related to any plugin/mod/extention as it is displayed in a default install of Firefox.
Issue still exists in 2.0.0.13 update. Bug 389502 is a tracking bug for issues related to this problem.
The "Windows cannot find 'http: " error message still pops up in the latest Mozilla Firefox 3 Beta 5 ( Build 2008032620 ) when you click on a short cut in Windows XP when Firefox is not running.
Issue is also present in FF3rc1 On Vista.
Attached image Error Message —
Seeing same problem here. New in a one of the more recent versions of TB. I don't believe I ever say this before 2007.
Follow up--Step to Reproduce #1, at least, is not required. Clicking on a mail announcement link displayed by Yahoo Messenger results in the very same error, for me.
Note: this is more likely due to the XRE startup code which restarts on startup, etc. and not due to shell integration.
Well, it's now 2009 and the bug is still there (FF3.0.5/Vista).
Whiteboard: [notacrash]
(In reply to comment #20) > See also https://bugzilla.mozilla.org/show_bug.cgi?id=155241 Bug 155241 is about taking over as the default handler for handlers the app can take over and we already provide that option in the Firefox installer and we also provide the option when running Firefox as long as the user doesn't turn off the notification. This bug is about DDE (dynamic data exchange) though that isn't obvious from the error message, etc. This bug will be taken care of by bug 491947
Depends on: 491947
Thanks, and sorry for all the spam. This is above my paygrade, as they seemed to to me to be describing the same problem.

I think this was fixed by the removal of DDE so resolving as wfm. If you are still experiencing this please comment in this bug or better yet please file a new bug. Thanks!

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: