204.06 KB, application/zip
47.18 KB, image/png
I don't know if this is an N6 bug, but using recent branch candidate builds (most recently 10-31-14 MN6), all of my HTML documents have a generic Windows icon, rather than the 'N' icon that other N6 documents (like jpeg files) have. Also, seemingly related, when clicking on them to open, I get an alert saying 'Cannot find the file <full path> (or one of its components. Make sure the path and filename are correct, and that all required libraries are available.' After dismissing the alert, the page loads fine. I find the part about ensuring all libraries are present to be a very strange thing to be admonishing users about. "My library is just down the street, does it need to be open for Netscape to work?"
are you referring to desktop shortcut icons or minimized window icons? am guessing the former... this might be a desktop integration issue.
Neither, I'm talking about HTML documents, the icons for saved HTML files themselves appeared generic. After talking with Bill, I managed to get these file types taken over by IE,so that it handles them as its own with no problems. However, N6 still ignores them, leaving me to launch IE when I click on them.
nav triage team: Sounds like desktop integration issue, but don't think we'll do anything for beta1. Marking nsbeta1-.
Marking nsbeta1- bugs as future to get off the radar
I'm still seeing this error on opening documents, but I'm hoping that nobody else is. Has anyone tried this on Win98? It seems fundamental to me that a product be able to open its own files without an error.
I see this on win2k (and win95 [noted on bug 44714, and I think there may be a duplicate of this bug somewhere, but I couldn't find it]). I know Bill has a big load of bugs (as everyone does), but I don't see why this is being futured. It is fundamental behaviour, as trudelle notes.
re: the document icon I heard of a mysterious hidden feature of windows whereby it caches desktop document icons. Supposedly, if you find the file where it caches that info and delete it, it can make problems such as this go away. re: the spurious desktop error box Things seem to work, right? It's just that Windows thinks something is wrong and puts up the alert. I've had trouble reading Windows mind to know what it is that it thinks is wrong. It has something to do with DDE and maybe timing of the DDE request with respect to the call issued to start Mozilla. Does the behavior differ if Mozilla is already running? There's some work going on in the DDE arena to make us work better with other clients, so maybe we can take care of this particular client (the Windows desktop) at the same time.
I haven't noticed any difference if it is already running, an error alert always appears. The way I'd put it is that things 'seem' not to work, due to the error alert, but the document is actually opened. This is extremely embarassing behavior, and should be fixed. Sprinkling magic keyword dust, cc'ing people who might care. Who else might be able to fix this?
I am not seeing this behavior on 2001061104 win2k although I feel certain I've seen it within the past week, and have certainly seen it many times before. Just now I checked the Moz open/Moz not open cases, and the -turbo case, and wasn't able to produce the error. I've also had the case where all html documents are marked for IE, and no number of Moz installs or clicking of checkboxes in Edit, Preferences, would correct that. A month or so ago I removed Office 2k, installed Office XP (for Outlook), uninstalled Moz with the Remove Program function, reinstalled Moz, and now *much* is right with the world: - NS icon for html; - Moz starts when I click an html or type its name at the command prompt (though twice); - Moz opens on click of a link in any kind of Outlook mail (though twice); I frankly think there's a level of windows weirdness that is beyond Moz'/NN's control although it would be great to understand that better.
See my comments under bug 58848. I think the fix I'm working on for that bug will also fix this one.
nav triage team: This is really annoying for users. Also, we're hoping the fix for bug 58848 might fix this too. Marking nsbeta1+ and mozilla0.9.3
--> me to look into
Can people still reproduce this?
Yes, I can on win2k. I have generic icons for '.html' files, although the text for 'Type' in file explorer is 'Mozilla Hypertext Markup Language Document'. When I double-click, the document is loaded into a mozilla window, but I also get the message about 'Cannot fine ....'.
I can reproduce it on several systems, NT, win2k amoung them. Turning DDE off for the file type improves the behavior but it isn't clear that that doesn't break other things. Uninstalling NS4 causes HTML icons to show mozilla's icon, fwiw. jpg and gif files open moz but don't actually show, either.
Removing nsenterprise nomination.
I see this error when opening "http://bugzilla.mozilla.org/" with the "Run" dialog in Windows 2000 SP 2 (5.00.2195). This is in mozilla 0.9.3 -- I haven't tried it with the latest nightly on windows. --------------------------- http://bugzilla.mozilla.org/ --------------------------- Cannot find the file 'http://bugzilla.mozilla.org/' (or one of its components). Make sure the path and filename are correct and that all required libraries are available. --------------------------- OK --------------------------- I actually believe that I don't see the other (separate?) problem reported in this bug. All of my html files have a gecko icon, which is certainly mozilla specific.
I'm not currently seeing this using latest build on Win98, but I still think it is a very embarassing defect, and if it affects all Win2K users then we should fix it for eMojo. adding nsbranch keyword pixy dust, jrgm: please + if appropriate.
Still happens in 0.9.4 (same windows install)
nsbranch+ -- my comment of 2001-07-28 01:34 is still the state of affairs for me (win2k). We really need to sort this out for emojo.
Marking PDT-, until we see a patch.
There aren't any comments on this bug since the 17th of Sept. Can QA regess against the Netscape commercial builds and determine if this is still a valid bug? If so, and we can get fixes/reviews in the next day or two, please mark as nsbranch+ which will get this on the PDT radar. Else, mark is as nsbranch-. Also, can someone comment in the bug how serious you think this is? PDT is only accepting "stop ship" bugs such as data loss and loss of major functionality. There is a comment that this is nsbranch+ but the keyword hasn't been updated to that state. If it should be then please do.
This bug is pretty annoying for me -- When I open a page using the "Run" dialog box, after dismissing the error dialog, the run dialog comes back, so I have to dismiss that too.
Still happens for me using recent branch build on Win2K. Doesn't sound like this fits the current PDT criteria though. jrgm?
jrgm is out until 26th. I wonder if this is affecting all Win2K users.
It affects my two win2k systems plus two others I know of. It also happens on two NT machines where we've given users NS6.1 and before that Moz. I'm sorry to go non-tech, but... I know you have a lot to do, but I beg you not to ship NS with these kinds of obvious, very visible problems. NS6.x is now blocked out on major systems on our campus because of stuff like this; getting it unblocked just isn't happening. Our users do notice, they do complain, telling them "get over it" isn't acceptable *to them*. Sorry for the spam.
Blake, do you have any interest in fixing this defect, or may I reassign it?
John - Can you look at this one on WinXP?
This is not so interesting, if this is not happening on WinXP.
I don't see this with the 9/26 branch build on _a_ winXP machine. I don't know if that means _all_ winXP machines. It is still reproducible on my win2k machine, but not on another (random) win98SE machine. Double-click-to-open is such a fundamental, universal UI gesture that it seems that we've dropped the ball bigtime if it doesn't work on every system.
I cannot reproduce in XP either. I could reproduce on 2k at Netscape.
Assuming that means you don't have Win2K now, should we reassign to law?
I have 98 and 2k and xp tribooted.
what are the chances this will make 094?
Using 10-01 branch build this is not reproducible (and I used to have this problem as well). Marking PDT-, remove minus if you disagree.
> Using 10-01 branch build this is not reproducible ... ... on win98 and winXP. It does occur on NT and 2K, as noted on 9/27. Removing PDT- until I hear that nothing will/can be done to fix this.
I'm using NT, SP6 and I don't see the problem. Anyway, marking PDT for review
With today's build on win2k, a double click on a .html brings up an empty Moz browser window--nothing on the page, nothing in the location bar (same thing has been the case for a long time with jpg, gif, etc.). I have the default protocol and document type settings, I believe.
I was asked for an ETA on this. I don't have one at the moment but have been looking into this for about the past hour. I'm still unaware of what DDE issue would cause this to happen on some win2k machines. I wouldn't consider this a stop ship given that it doesn't seem to occur on 98 or XP, and only occurs on some NT machines, but I can see where the concern would lie given the target for this release, so am still actively looking into it. John, just to be sure, could you give this a go on NT/2k with a trunk build? (I don't have the problem in 2k, and Frank doesn't seem to either, although he has a different one I don't see.)
opening HTML docs from the desktop wfm using branch/win2k.
Should I file another bug for this "open blank" behavior on html and on the usual image types?
In both today's branch and trunk comm. builds, when I double-click on a folder item (which has a NS6 logo and says "Mozilla Hypertext Markup Language"), the document is loaded correctly, but I receive this 'Cannot find the file ... (or one of its components). Make sure the path and filename are correct and that all required libraries are available". I dunno. Maybe I have some bad cruft in my win32 registry. Which keys should I try to remove to get back to a clean slate (although if that fixes it, then we need the installer to get in a clean up this kind of stuff). (Frank: yes, file a separate bug for what you are seeing.)
Flailing away in the dark, I deleted these hives (exported them first for later inspection): HKEY_CLASSES_ROOT\NetscapeMarkup HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla But, I still get that error coming up. (Something else to delete? Which file associations?).
nsbranch-, unless jrgm (or anyone else) finds a smoking gun that will affect a significant number of target users.
I'm not familiar with Netscape terminology. What would a "Smoking Gun" look like in this case?
<assuming you are serious> This is not NS terminology, it is even in my copy of Merriam-Webster's dictionary: conclusive evidence or proof. Right now all we have is anecdotal evidence that this is sometimes a problem for some users. We'd need much stronger evidence than that to hold up our release.
I was serious. I was asking you what kind of thing would you consider to be conclusive evidence or proof? A lot of user testimonials? One person coming up with a detailed repro case? Something else? Since I can't help with collecting feedback from a lot of people, I'll hope that the detailed repro case will be at least part of the smoking gun. 1) Installed Windows 2000 Professional Typical Settings, all defaults for options. 2) Reboot Used default settings for Network Identification Wizard3) After being logged in as Test User Open Run dialog http://www.mozilla.org/ 4) Internet Connection Wizard pops up. I select "I want to set up my Internet Connection manually, or I wnt to connect through a local area network (LAN)" 5) I select "Next" and then "I connect through a local area network (LAN)" 6) I select "Next" until I get to the "Internet mail account" where I say "No." 7) I select "Finish" 8) Internet Explorer opens. I go to the releases page http://www.mozilla.org/releases/ and download http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.4/mozilla-win32-0.9.4-installer.exe 9) I run it, and the installer comes up. I hit "Next" a whole bunch, and "Yes" when it asks me if I want to create the C:\Program Files\mozilla.org\Mozilla. "Next" some more, and finally the "Install" button. 10) Up pops the newly created "Mozilla" start menu directory window. 11) I double click the mozilla icon in the system tray. 12) up pops a dialog box entitled "Windows Integration" which asks me if I want to set up windows to use Mozilla for "internet shortcuts." I say "Yes" 13) up pops mozilla. 14) I close all of the windows, pressing "OK" when the quick launch dialog box comes up 15) I hit Start:Run, type in http://www.mozilla.org (well, it was actually there already) and press "OK" 16) The dialog box of doom comes up. (Cannot find the file 'http://www.mozilla.org/' (or one of its components). . .). Quick on its heels, the mozilla window pops up with http://www.mozilla.org/ loaded in it. I don't know if this counts as a smoking gun, but maybe it will at least count as one of the gun parts. =) I will attach a zipfile of screenshots along the way for more visceral proof.
Created attachment 52431 [details] zip file of PNG screenshots of the clean win2k pro repro of this bug.
wtanaka: Some question whether Start/Run->URL falls within the scope of internet shortcuts, file types and protocols that moz/NS should handle. What they really want to see are reproducible steps within unquestioned bounds, e.g., double click an html file on your hard drive, double click an actual internet shortcut on your desktop. They believe the behavior happens, but not to enough users to justify the time of fixing it now. While I'd seen it on every platform, the data in the bug suggests it is now a win2000, maybe NT, issue. Now, for those of us in organizations just deploying 2000 (not XP) over NT, this is of little confort.
Thanks Wesley, I can now reproduce this once again on my Win2K machine, just typing an URL into the Run dialog long after install. However, I don't think this particular usage case will affect a large number of users enough for us to take a fix this late in the release. Frank, I think you've characterized our motivations a bit askew, it isn't the time to fix it (which we are quite willing to invest, although Blake currently owns this), it is the risk that any fix could have side effects that will introduce far worse regressions, affecting many more users. We have to be very careful about this in the endgame of any release. However, if Blake finds a very simple/safe fix, we could reconsider.
Peter: talking to us about "risk" is a helpful elaboration of decision making within development projects--it is not bad to hear what you all are thinking now and again. Thanks. FWIW: using 2001100610 on win2k, I can hand start/run "www.ibm.com" and exactly the right thing seems to happen. But opening from the the file system still brings up blank. I filed a bug on that that has been duped against something else. One wonders if there is a connection...
Frank: Again, from a clean install of Windows 2000: 1) I Install mozilla 0.9.4 from http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.4/mozilla-win32-0.9.4-installer.exe doing the same steps to associate it with links and html files and such. 2) I run it, and it opens up to http://www.mozilla.org/start/ 3) I drag the little bookmark icon next to the location text field over to the desktop, to get a link. 4) I close the mozilla window 5) I doubleclick the "Getting Involved with mozilla.org" icon that is now on my desktop (Interestingly enough, the icon is an IE icon) The dialog box pops up (Cannot find the file 'http://www.mozilla.org/start/' . . .) and then the mozilla window opens to the correct page.
Created attachment 52471 [details] Screenshot of repro case, double-clicking on an "internet shortcut"
Removing [PDT] grafitti because this was minused by component team.
*** Bug 101932 has been marked as a duplicate of this bug. ***
*** Bug 117963 has been marked as a duplicate of this bug. ***
In bug 115239, email@example.com (Juha Luoma) writes: Win32 API function ShellExecute can used to open the specified web page in the default web browser. An example of such a function call is ShellExecute(hwnd, "open", "http://www.company.com/", NULL, NULL, SW_SHOWNORMAL); According to the Win32 API documentation, ShellExecute returns a value greater that 32 if it succeeds. But, when Mozilla is installed as the default web browser, ShellExecute return an error 2 (ERROR_FILE_NOT_FOUND) even if the browser is started and the page is displayed correctly.
*** Bug 115239 has been marked as a duplicate of this bug. ***
I don't know what else to do here. I only have XP now, and can't reproduce this, via shortcuts, the Run dialog, or by calling ShellExecute directly as outlined in bug 115239. I'm going to pass this off to law because he at least has 2k last I heard. I can't figure out what we'd be doing wrong to cause ShellExecute to return "file not found" only on (it seems) NT-based and 98 machines.
In about two months we are going to update all of our machines from NT to 2000. Sure, many PCs for consumers ship with XP. But environments like ours are very much standardized on 2000, for at least the next year, and more likely two. It is important to us--and I hope to Netscape--that the browser integrate well into 2000 and into other applications like Outlook, WordPerfect, etc. Sorry for the non-tech evangelism...
Nominating for nsbeta1
I think this is also related to two Moz windows opening any time I click a link in a message in Outlook. This has been bugging me for a long time, I'll try and look into it in the next little while. I think Juha may have been on the right track in bug 115239, so I'll start checking things out in nsNativeAppSupportWin.cpp. Bill: Feel free to assign this over to me.
Well, that was unexpected. In looking through the registry I found: HKEY_CLASSES_ROOT\http\shell\open\ddeexec I deleted that key, and now everything works fine. URLs work from Start > Run and I don't get double browser windows from MSN Messenger (same symptom as Outlook). I did the same for HKCR\ftp, and now I can type ftp://foo.bar URLs in Start > Run. I think that the ddeexec for http pointed to IExplore, I know the ftp value did. I would have looked closer, but I didn't think it was going to do anything! Would anyone that's having the problem care to try this out? I, of course, recommend backing up the registry keys before deleting them!! Do as I say, not as I do...
OK, I just found another bug where Bill talked about what I just said. What I found basically jives with bug 59078 comment 78, although I wonder why we're keeping the ddeexec subkey around. Why not just delete it entirely?
Just FYI, you'll need to delete the registry key from the HTTPS section as well, or you'll get the error if you try to go straight to an SSL page...
Also, just FYI (again), deleting the ddeexec key disables clicking on links from Outlook, etc. if IE is your default browser, so this can't be the correct fix...
I can confirm the bug is "fixed" using Mozilla, but as it creates problems with IE as the default, there either needs to be a way to create/remove the key at the change of the default browser, of fix the shell command executed itself...
my proposal is that we change the command to use -turbo, it's kinda like -nohome and the result w/ a DDE command would be correct. I know i've made that comment before, but we have too many bugs about this, so it must have been in one of those. care to try that?
I think these are all the same bug - this one, bug 88083, and probably a whack of others. See below. There's still a problem with .html files opening a single, blank window, (bug 59078 which I just commented in) that I think is separate from this. I just removed the "ddeexec" key and now everything works swimmingly, including Office 2002. I can: - open URLs from Start > Run - open ftp:// URLS from Start > Run (I also removed "ddeexec" for "ftp") - open links from other programs in a single new window (no duplicate window opens) - open links from the desktop in a single window - click links in Outlook 2002 to open in a single new window - click links in Excel 2002 to open in a single new window - click links in Word 2002 to open in a single new window I think we should just toast the "ddeexec" subkey completely for: http, https, ftp, mailto, and htmlfile (bug 59078), pngfile, etc. This is only if the appropriate integration is selected, of course.
Hey Dean, thanks for working on this. I was using bug 59078 to tackle this issue (note that I made this bug dependent on that one). I discovered this solution quite some time back, but haven't gotten around to coding it up. There are some issues with the way the code that twiddles registry keys works. I don't think there is support for removing an entire key. That's easy enough to do. But conceptually it poses some problems because the code is designed so we can reset the registry to the way it was before we messed with it (if the user changes their mind about using us to handle a given file type, etc.). To do that properly would require us to enumerate the contents under ddeexec and save everything somehow so we would know what to restore. Maybe we should just bail on that and only save the known subkeys like application and topic. Anyway, the code goes in nsWindowsHooksUtil.cpp, if anybody wants to tackle it before I'll get to it.
Sorry for the spam. Bill and Dean, is there support for renaming a registry key? I know that when I'm personally mucking with registry keys, that's what I usually do: rename a key to see if I can remove it safely, and rename it back if things don't work. That way, you wouldn't have to enumerate the key's contents, and restoring things is as simple as renaming it. Actually, I just realized: is there an API to rename keys? If not, then forget what I said :)
Spam: Moving out bugs that there is no time for. Please note that some of these will hopefully be fixed in the course of fixing bug 59078. I just can't commit to fixing them all.
*** Bug 124855 has been marked as a duplicate of this bug. ***
nsbeta1+ per Nav triage team
*** Bug 65741 has been marked as a duplicate of this bug. ***
There's some interesting info in bug 65741 about this.
Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.
*** Bug 130899 has been marked as a duplicate of this bug. ***
*** Bug 129770 has been marked as a duplicate of this bug. ***
This should be fixed by the patch for bug 59078 that just went in. If you can still produce this error, please re-open.
*** Bug 137363 has been marked as a duplicate of this bug. ***
I don't think 137363 was resolved in that patch. 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.
I am having this problem on Firefox 0.9.2 with Win 2000 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2). IE was the default browser but this is now set to Firefox. Currently neither browsers are checking whether they are the default. Can this bug please be reopened.
This bug is a dupe of so many of the same bugs it is getting crazy. I has happened for me ever since 126.96.36.199 (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)