Closed Bug 137363 Opened 23 years ago Closed 15 years ago

Windows error box when opening URL from Start->Run or desktop icon

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: pvz, Unassigned)

References

Details

Attachments

(1 file)

Desktop shortcut to Earthlink Web Mail
19.13 KB, application/octet-stream
Details
1. Click your Start button. 2. Select Run. 3. Type in your favorite web address (www.mozilla.org) 4. Click OK 5. Observe the dialog box. :) A windows dialog box pops up, stating: ----------------------------------------------------------------------------- http://www.mozilla.org/ [X] Windows cannot find 'http://www.mozilla.org/'. You may have typed the name incorrectly in the Run dialog, or another open program cannot find a system file. To search for a file, click the Start button, and then click Search. [ OK ] ----------------------------------------------------------------------------- But then, the page launches just as it should.
Oh, sorry, I forgot to mention, this also happens if you make a shortcut from the desktop (i.e. drag the icon from the url bar to the desktop then double click)
Alqys add the build ID in a bug report. This one should be a dupe of bug 58770, please reopen if you see this with a recent nightly build. *** This bug has been marked as a duplicate of 58770 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
I can reproduce the problem. Steps to reproduce. 1. Set Firefox as your default browser after having IE as default. 2. Start->Run-> www.testing.com or ftp://www.ftp.com Results: A windows error message will come up saying "Windows cannot find 'www.testing.com'." Just before opening Firefox and taking you there. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040430 Firefox/0.8.0+ Changing the default browser to Mozilla stopped this error. Also, after changing back to Firefox, there was no error. But it seems to be when you make Firefox default after IE, it errors.
Sorry. Also not the same as bug 58770. It was not resolved with that patch.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Do you get the same if you make Mozilla the default browser after IE ?
I wonder if this is still a Browser bug, or if its Firefox specific. Something has changed recently in Firefox (no idea what, or if the change was inherited from Browser) that is causing Firefox to display this behaviour when you set it as the default browser. If you start up Firefox 0.8, and set the default browser using that, then the problem goes away. It's only recent builds that exhibit this behaviour when you set it as the default browser. Steps to Reproduce: 1. Load up new build of Firefox 2. Set as default browser 3. Close Firefox 4. Go to Start | Run 5. Enter "www" and hit enter. Expected Results: www is passed to Firefox, and Firefox goes to the page if there is a www cname in your domain, or it does something else if its not. Windows doesn't care either way. Actual Results: Same as expected, but a Windows error box also pops up saying that www could not be found or something. I think this may be Firefox specific and belong in Firefox General, but I'm not sure. Whatever caused this to happen broke recently (after Firefox 0.8).
OS: other → Windows XP
WFM: Gecko/20040606, Windows XP Followed the steps in comment 0 and no problems.
Manually deleting the registry key HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec seems to fix this problem.
I can confirm with the 0.9 nightly builds between 05-24-09-0.9 and 06-09-00-0.9 on XP SP1 and XP SP2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+ to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ Comment #9 fixes this for non-https urls, you should also delete HKEY_CLASSES_ROOT\https\shell\open\ddeexec This summary is much clearer than that of bug 246078.
Works for me. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+ (bangbang023)
Confirmed in Firefox 0.9 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9) under XP SP1. The suggestion in comment #9 solved the problem for me.
*** Bug 242715 has been marked as a duplicate of this bug. ***
There is a very similar bug to this one (dupe?) filed for Firefox. See bug 246078.
*** Bug 248596 has been marked as a duplicate of this bug. ***
From the dup: "I am posting this so that the developers can in the next release make sure than when Mozilla is set to the default browser that it deletes the following registry key and all there sub-keys and values' HKCR\HTTP\shell\open\ddeexec HKCR\ftp\shell\open\ddeexec HKCR\gopher\shell\open\ddeexec HKCR\https\shell\open\ddeexec If anyone else on this forum has had this problem before you now know how to fix it. It is a very rare and anyone who has had this problem, it is because these DDEExec entries make windows look for IE starting instead of Mozilla (their values point to IE)."
I had this problem, but solution presented in comment 16 fixed it. I had a similar problem, when launching windows w/ Bayden Slickrun, when firefox is the default browser, it would create 2 windows both at the same location, and when launching from start->run it would create one window, and another window would error. Windows XP Pro Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
This bug occurs in both Firefox 0.91 and 0.92. Moreover, the same error appears if one saves a bookmark to the desktop by, for example, dragging the icon in the URL bar to the desktop and then double-clicking on it.
Per von Zweigbergk, could you please mark this bug as a duplicate of bug 246078 ? It is know well known under this number and even listed on http://www.squarefree.com/burningedge/ Until know there it is not fixed in the latest nightlies but it is marked as blocking-aviary1.0RC1 Here you can get a .reg file to fix the Problem: http://johnhaller.com/jh/mozilla/firefox_bug_246078.asp
No, the Firefox and Seamonkey code is branched, so this might have to be fixed twice.
How does one apply the fix from comment #16 on a per-user basis? That is, what do I change under HKEY_CURRENT_USER (as opposed to HKEY_CLASSES_ROOT) such that it believes that the "ddeexec" key does not exist? Right now it seems to grab this value from HKEY_CLASSES_ROOT for me even though I try creating an equivilent empty key in HKEY_CURRENT_USER\Software\Classes\... Any ideas?
Desktop URL shortcut yields error when Mozilla or Firefox is default browser. The exact same shortcut does not yield an error when MS Internet Explorer is the default browser
using firefox 0.9.2 , still having this problem... the only fix is at http://johnhaller.com/jh/mozilla/firefox_bug_246078.asp and isn't this the same as bug #246078 ?
bug #246078 is fixed, so this bug must be fixed, no?
Product: Browser → Seamonkey
Assignee: matti → general
QA Contact: imajes-qa → general
I have this problem with Vista 6000 Ultimate version as well.. None of the fixes solve it..
Have this problem with Vista Ultimate too. Fixes don't solve it.
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)
I just installed 3.0.0 (over an existing 2.0.x installation) and it "helpfully" recreated those ddeexec entries, which broke all my links from other applications. Can someone *please* either make it stop creating these or force it to actively delete them when Firefox is selected as the default browser?
It's now over 5 1/2 years since this thread was created, and the bug is still there. I get it using Firefox 3.0.5 and Vista Business. As people have noted above, the registry edit is only a temporary fix. Firefox recreates the broken registry entries every time it auto-updates itself.
I'm running FF3.0.6 on XPProSP3 and occasionally see the problem. Rather than hacking the registry, I find letting Internet Explorer(7) set itself to the default browser and then let FF reset itself to default clears the problem--an annoyance but a bit safer than a registry hack.
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070529 SeaMonkey/1.5a
Status: NEW → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → WORKSFORME
I can confirm Lowell's fix (FF 3.6.10 XP SP3). (This is the opposite of the behaviour in #4). Setting IE as default browser creates almost identical Registry settings under HKCR\http (only the Application key changes). The bug is now fixed for me in Firefox with those keys set just the way Firefox creates them when it sets itself as default browser (e.g. after you delete the whole of HKCR\http). I therefore don't believe that deleting ddeexec is really the right thing for Firefox to do. What really causes this bug and what does setting IE as default browser do that fixes it for Firefox? It doesn't seem right to close the bug without understanding why the work-arounds work.
So it seems, as I understand the problem in looking how FF sets things up. The problem occurs because DDE is the default/preferred handler over running an external command (DDE can invoke an already in-memory DDL), but FF has been unable to figure out how to implement such a handle to take the place of the IE handler and provide more efficiency as well? Seems like all the workarounds above get created because something reactivates DDE handling and Windows goes back to 'efficient' calls to an (possibly already loaded handler). Wouldn't be best solution be to have FF install it's own handler? Or would that be too much like 'right'? What amazes me in so many areas, across products, how many hours if not weeks and months are wasted by user communities in working around a shortcoming in a product that would take maybe an hour or less of code to fix in the product -- thus saving untold time in the future for all those users who will again encounter the problem.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: