Closed Bug 389502 Opened 17 years ago Closed 8 years ago

[meta] "Windows cannot find .... Make sure you typed the name correctly, and then try again."

Categories

(Core Graveyard :: Tracking, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: jruderman, Unassigned)

References

(Depends on 2 open bugs)

Details

(Keywords: meta)

Tracking bug for bugs about "Windows cannot find .... Make sure you typed the name correctly, and then try again."  The ellipsis might be a URL or might be "firefox.exe".

Seeing bug 389312 and bug 388950 filed within days of each other makes me worry...
Flags: blocking1.8.1.6?
In bug 388239 comment 6, Simon Bünzli said:

"That's bug 371031, probably in combination with bug 342885 resp. bug 333907"

The error message in bug 371031 is "failed to open file http://gmail.com, check the filename and try again", compared to "Windows cannot find .... Make sure you typed the name correctly, and then try again." here.  I'm not sure those are the same but I'm guessing they are.
Depends on: 371031, 388239
Bug 371031 is only one possible symptom of Firefox being stuck during DDE initialization while Windows sends the first DDE transaction: this happens while the Restore Session prompt is visible.

I don't know whether there are other obvious causes or if it's plain and simply a race condition happening during startup which causes all the other bugs reported here, though. bsmedmerg or rstrong might be able to determine the actual issue.
Flags: blocking1.8.1.6? → blocking1.8.1.7?
Flags: blocking1.8.1.7? → wanted1.8.1.x+
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.
System: XP Home with Service pack 2
After installing FF 2.0.0.7.

---
Once again, installing a FF update causes a 
Windows popup to appear "Windows cannot find ..." 
if I click a desktop link to an html page
when FF is not already open. Following the
popup (and sound), FF opens the page normally.
If FF is already open, this doesn't happen.
Very annoying.

I got rid of this problem by modifying the registry
after installing 2.0.0.5 and 2.0.0.6.  
Now I installed 2.0.0.7 and the problem has returned.  
Did I mention this is very annoying?

This should be fixed by the developers.

The bandaid:
Put this code (which I found somewhere) into
a .reg file (i.e., fix_firefox_again.reg) and then
right-click / merge it into the registry.  Voilá!
The problem is gone again (at least until 2.0.0.8 
comes out).

DO NOT HOLD ME RESPONSIBLE FOR YOUR FUTZING WITH
THE REGISTRY!  CREATE A RESTORE POINT BEFORE YOU
RUN THIS.

----cut----


Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\FirefoxHTML\shell\open\ddeexec]
@=""

[HKEY_CLASSES_ROOT\FirefoxHTML\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\FirefoxHTML\shell\open\ddeexec\Topic]
@="System"

[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\ddeexec]
@=""

[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\ddeexec\Topic]
@="System"

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec]
@=""
"NoActivateHandler"=""

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec\Topic]
@="System"

[HKEY_CLASSES_ROOT\https\shell\open\ddeexec]
@=""
"NoActivateHandler"=""

[HKEY_CLASSES_ROOT\https\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\https\shell\open\ddeexec\Topic]
@="System"

[HKEY_CLASSES_ROOT\ftp\shell\open\ddeexec]
@=""
"NoActivateHandler"=""

[HKEY_CLASSES_ROOT\ftp\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\ftp\shell\open\ddeexec\ifExec]
@="*"

[HKEY_CLASSES_ROOT\ftp\shell\open\ddeexec\Topic]
@="System"

[HKEY_CLASSES_ROOT\gopher\shell\open\ddeexec]
@=""
"NoActivateHandler"=""

[HKEY_CLASSES_ROOT\gopher\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\gopher\shell\open\ddeexec\Topic]
@="System"

----cut----
Depends on: 396815
I've found this on multiple machines, so it does seem to be a systematic problem. Sorry not to be able to give more detailed info but I thought it would be useful to report that it seems a common problem.
An update installation of Firefox (in this case, 2.0.0.8)
writes these entries to the Windows registry: 

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec]
@="\"%1\",,0,0,,,,"
"NoActivateHandler"=""

and 

[HKEY_CLASSES_ROOT\https\shell\open\ddeexec]
@="\"%1\",,0,0,,,,"
"NoActivateHandler"=""

I tested very small changes and found that resetting (AGAIN) 
these two entries to:

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec]
@=""
"NoActivateHandler"=""

and


[HKEY_CLASSES_ROOT\https\shell\open\ddeexec]
@=""
"NoActivateHandler"=""

fixes the problem for http and https desktop links.  I usually don't have gopher
or ftp links, but presumably a permanent fix should anticipate those as well.

Depends on: 402546
(In reply to comment #6)
This seems to have stopped generating duplicate URLs from launching but not the error message. I'm no registry pro so I might have entered the data incorrectly however.
This bug is a dupe of so many of the same bugs it is getting crazy. It 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)

Once again... automatic update to 2.0.0.13 created the ddeexec keys again and the error message came back. Took a browse through registry and it seems only a few of the keys were recreated this time though! 

The following keys were recreated this time:
HKCR\FirefoxHTML\shell\open
HKCR\FirefoxURL\shell\open
HKCR\ftp\shell\open
HKCR\gopher\shell\open

So, it seems as if some progress was made, but the underlying issue still exists.

Verified once again on both my XP and Vista machines. Only add-on installed all computers is the google toolbar.
I can confirm what Brian is saying. It would be nice to see someone at Mozilla take ownership of this report. It is disheartening to see it unassigned and without a target milestone after all this time.

BTW: If you guys want to see this issue fixed, maybe you should vote for it. There is a "votes" link in the top-right corner of this page. Maybe Mozilla will take it more seriously if they see a lot of votes.
(In reply to comment #10)
> I can confirm what Brian is saying. 
> There is a "votes" link in the top-right corner of this page. Maybe Mozilla
> will take it more seriously if they see a lot of votes.

Me Too!

This also affects other products, like Daves Quick Search Deskbar  and in some cases Google Toolbar. 
I can confirm these anomalies.  Additionally, the AVG v8 browser add-ins are now completely non-functional.  Firefox opens with "TypeError: avg_DTfox.prefs has no properties."  Re-installation of AVG v8 internet security suite does not correct the problem.  I suppose this flaw will not be corrected; it seems that the Firefox development team simply ignores the problems posted in these forums.  Were it not for the amount of password and personal data that I've accumulated in Firefox, I'd stop using it.

Won't one of you development folks take charge of getting the coding straightened out?
Version: unspecified → Trunk
This evening's update to version 2.0.0.14 has once again caused this bug to re-appear on all my computers.  Any attempt to open a desktop shortcut to a URL, or a link within an Outlook email, triggers an error, like this:

"Windows cannot find "http://....". Make sure you typed the name correctly, and then try again. To search for afile, click the Start button, and then click Search."

The URL does, in fact, open up, but only after this annoying "error" message appears.  This problem has been going on for well over a year...I can't believe it's been around this long, and reported by so many people, and seems either ignore, or denied (some of the other bug reports are marked as Verified Fixed).

The only way to resolve it is to delete the DDE info in file associations.

Note: if FireFox is already running, the error does not appear.  It only appears if FireFox is NOT currently running.
(In reply to comment #13)
> This evening's update to version 2.0.0.14 has once again caused this bug to
> re-appear on all my computers.

I have the exact same problem as Gary German.

I just updated to 2.0.0.14 and got the bug back.
(I think the bug first appeared on my WinXP when i updated to v2.0.0.13. I don't use any toolbars or addons at all, so why my Firefox acts up like this is a mystery.)

Now I will perform the "File types edit" workaround again.
http://kb.mozillazine.org/Windows_error_opening_Internet_shortcut_or_local_HTML_file_-_Firefox
Exactly the same behaviour for me after the 2.0.0.14 update was applied.  I can't understand why this isn't affecting more people - perhaps it is, but they aren't reporting the problem.
It is truly amazing that every single upgrade generates this same glitch. I copied the fix about 10 iterations ago and everytime I upgrade I try to launch Google, get the "Can't find..." error message, bust out the fix and I'm fine.

Shame on Mozilla for allowing this to go on indefinitely. It sort of makes you pine for the upcoming IE8, right?
Adding my voice to the chorus.
PLEASE fix this bug ... it should have been squashed many updates ago.
Perhaps if the severity of this problem was changed from Normal to Major, 
someone will take a look at this problem.

It certainly isn't "new" either.  It's been floating around for almost
two years. 
Yeah, between FF memory and cpu hogging, failures in add-ons, and this continuing irritation, I've gone back to using IE7 as my default browser.

It's a shame, but I'm just tired of having to babysit the software, and hack my registry settings every time an update gets released.

I tested the version 3.05 beta, but my favorite add-ons aren't supported, the program seems to suck up memory and cpu cycles as much as before (even with all add-on's disabled), and this bug is not fixed in version 3 either.

I loved FF back in the days of IE6, but it seems to have definitely fallen behind the times. Here's hoping the developers can get it back to "best of breed" in future, but I don't see that happening anytime soon. 
Guys, please don't use this meta bug for bugspam. Nothing you have reported will help to solve remaining issues. Please give helpful comments to one of the bugs which are listed in the depending list. Thanks!
(In reply to comment #20)
> Guys, please don't use this meta bug for bugspam. Nothing you have reported
> will help to solve remaining issues. Please give helpful comments to one of the
> bugs which are listed in the depending list. Thanks!
> 
I hardly think this stuff is "spam", sir.  I have installed FF on probably 15 to 20 client's machines.  12 have asked me UNINSTALL it for them for a variety of reasons, with this one leading the group.  Because of the annoyance factor it IS a major bug. It would, more than likely, take a minor coding correction to resolve - - if someone were able to address it.
FIX: Someone else please confirm on your machine.

Control Panel> Appearance & Themes> Folder Options
Click "File Types" tab
Scroll down to "(NONE) URL:Hyper Text Transfer Protocol"
Click "Advanced"
In the "Actions" list Click "open"
Click "Edit" button
{Note contents of "message box"}
Uncheck "Use DDE" box
Click "OK"
Click "OK"
{If you go back the "message box" should now be empty}
Click "Close"

Try clicking on an URL link, it should work now.
FIX: Someone else please confirm on your machine.

Control Panel> Appearance & Themes> Folder Options
Click "File Types" tab
Scroll down to and Click "(NONE) URL:Hyper Text Transfer Protocol"
Click "Advanced"
In the "Actions" list Click "open"
Click "Edit" button
{Note contents of "message box"}
Uncheck "Use DDE" box
Click "OK"
Click "OK"
{If you go back the "message box" should now be empty}
Click "Close"

Try clicking on an URL link, it should work now.

Repeat this procedure for any file type that produces the error.
@Ripose, that is the same "bandaid" fix mentioned so many times before; it only works until the next time you update. In Vista you cannot do this anyway.
I did find a rather strange peculiarity though. I can't test this on many computers, so I am hoping others can either confirm or deny this:
For me this error only occurs on machines where Thunderbird is either not installed or not set as the default mail program.
Happens to me to with 2.0.0.14 on Vista. The error message text is as described above by Jesse R. (comment #1). I noticed that the general description involves Firefox _not_ open or crashed, or while the "Restore Session" prompt is visible. Neither of those apply in my case. I see it while Firefox is already open, not closed or recovering from a crash.

I think this one's particularly annoying because it happens only sporadically. Commenters have correctly pointed out that is has been around for a long time on XP as well as Vista. Unfortunately, I haven't been able to pin down what I've done different before it rears its head. I voted for it and hope it will get fixed ASAP.
Interesting development... I just installed Vista, then Firefox on my new PC. Did not see the error... until, I installed the Google toolbar (http://toolbar.google.com). This is the first time I have seen it on the new computer and Firefox did not update prior.

Anyone else NOT using the Google toolbar (or other Google product) and receiving this error?
I've fairly certain I've seen this without having any Google products installed. I haven't had Google Toolbar installed for years now but recently I installed Google Desktop search (so yes, now I have a Google product installed). But for at least a year beforehand I didn't have any such product installed and I still remember running into this issue.

Question: people provided a diff of their registry before and after applying Firefox updates. Wasn't that enough to track down which registry keys are being added which are wrong? Further, couldn't you search Firefox's source-code for those keys and see who is adding them?
The google install helps to acctuate the real issue. When FF is launched a small shell appears to be launched which launches the main instance, the small pre launch window then dies. Windows when it launches FF with DDE enabled expects to be able to communicate with that instance it opens, since that instance has already died you get the error. The google toolbar and many other apps that use DDE can aggrivate the problem even further. Likely one of the reasons this has not yet been addressed is the fact that the launch flow is the same on other platforms only without the DDE concern. The proper and only possible fix I forsee for this is to removed the DDE setting from the install package.
I don't have the google toolbar -- never have.  I have the problem on this and one other computer with every version of Firefox since BUT NOT INCLUDING 2.0 (e.g., the "Windows cannot find..." error message, immediately followed by the .htm file opening correctly).  Tonight I tried upgrading to 2.0.0.14, and it still is happening, so I uninstalled, used System Restore to go back, and put 2.0 back on.  With 2.0 everything is back to correct.

HOWEVER -- I do NOT have this problem on another computer.  All three are running Microsoft Windows XP 2002 Professional 5.01.2600 with SP2;  The computer that has no problem has a version acquired thru the Academic Alliance.

For what it's worth, none of the fixes mentioned previously (running the .reg file, editing the registry, etc) have worked for me at all.  I've tried running WinDiff to try to pinpoint changes, but have been unsuccessful.  For now I have to stick to v2.0.  
WOW!  I'm tentatively very excited.  Another computer, with a totally different installation of Windows XP Pro, had also recently exhibited the problem.  I was preparing to try running the .reg file (which has never worked in the past) - WHEN I DISCOVERED EVERYTHING IS WORKING!!!  I tried FF 3.0.3 on another affected computer, and it worked also (i.e. I can open a saved .htm with FF and not get the "Windows Cannot Find" error message). 

Did I say "WOW!"?  Wow.  Very happy.  Don't know if the change is in FF or in Windows, but I'm very happy.  I hope it stays.  Kudos to the responsible party, whoever you may be.
I have FF 3.0.5 and Vista Business 3-bit, and I am still suffering from this bug. I have tried all the workarounds published here and on other threads, but the problem comes back every time FF updates itself, so I have given up trying to fix it.
Stop Press: I just upgraded my "Vista Business 3-bit" to 32-bit. No change in the bug, though. ;-)
Firefox 3.5 is out.  Hmm, let's see...

"Windows cannot find... Make sure you typed the name correctly, and then try again."

Pfft.
I don't know if this has been discussed or not... I perused the thread, but I didn't see it.

In my case, it was the two IE Tabs I tried.  (IE Tab and Coral IE Tab).

They both have filters to grab file:// URLs by default.  Remove those and the problem goes away.

This might be a Vista only issue and may not be what this bug is all about.  Still, I thought you should know.
Depends on: 491947
Depends on: 604050
If I open an internet shortcut and Firefox happens to install an update right then I always get this error.

"Windows cannot find .... Make sure you typed the
name correctly, and then try again."

The web page will eventually open after the update installs but not without popping up the error message first.

I'm currently running FireFox 3.6.10 on Windows 7 x64 but I've seen this error on other operating systems such as Windows XP also.
Using FF 3.6.14 and XP and STILL this problem persists in 2011.  Wow.

Is there any time that FF will resolve this?  This user would be very pleased...
(In reply to comment #36)
> Using FF 3.6.14 and XP and STILL this problem persists in 2011.  Wow.
> 
> Is there any time that FF will resolve this?  This user would be very
> pleased...

Can you provide steps to reproduce for your case?
Depends on: 646835
Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.