Closed Bug 58770 Opened 22 years ago Closed 20 years ago

Error on opening any HTML document on double-click [win32]

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.0

People

(Reporter: trudelle, Assigned: law)

References

Details

(Keywords: helpwanted, Whiteboard: [Hixie-P0][adt3])

Attachments

(2 files)

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.
QA Contact: sairuh → jrgm
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-.
Keywords: nsbeta1-
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
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.
Summary: HTML documents have generic Windows icon, error on opening → Error on opening any HTML document.
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.
Keywords: helpwanted
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
Keywords: nsbeta1-nsbeta1+
Target Milestone: Future → mozilla0.9.3
--> me to look into
Assignee: law → blake
Target Milestone: mozilla0.9.3 → mozilla0.9.4
usability/polish, 0.9.4.
Status: NEW → ASSIGNED
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.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Removing nsenterprise nomination.
Keywords: nsenterprise
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.
Keywords: nsbranch
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.
Whiteboard: PDT-
Keywords: nsbranch+nsbranch-
Keywords: nsbranch-
Summary: Error on opening any HTML document. → Error on opening any HTML document on double-click [win32]
Whiteboard: PDT-
Keywords: nsbranch
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?
Keywords: nsbranchnsbranch+
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. 
Whiteboard: [PDT-]
> 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.

Whiteboard: [PDT-]
I'm using NT, SP6 and I don't see the problem. Anyway, marking PDT for review
Whiteboard: PDT
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?).
Whiteboard: PDT → [PDT]
nsbranch-, unless jrgm (or anyone else) finds a smoking gun that will affect a
significant number of target users.
Keywords: nsbranch+nsbranch-
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.
->0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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.
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.

Removing [PDT] grafitti because this was minused by component team.
Whiteboard: [PDT]
Blocks: 107067
Keywords: nsbranch-
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 101932 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.8 → mozilla0.9.9
*** Bug 117963 has been marked as a duplicate of this bug. ***
In bug 115239, jsluoma@iki.fi (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.
Whiteboard: [Hixie-P0]
*** 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.
Assignee: blaker → law
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → ---
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
Keywords: nsbeta1
Depends on: 59078
Target Milestone: --- → mozilla1.0
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 :)
Blocks: 123821
No longer blocks: 107067, 123821
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.
Target Milestone: mozilla1.0 → Future
*** Bug 124855 has been marked as a duplicate of this bug. ***
nsbeta1+ per Nav triage team
Keywords: nsbeta1nsbeta1+
*** 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.
Target Milestone: Future → mozilla1.0
Whiteboard: [Hixie-P0] → [Hixie-P0][adt3]
*** 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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** 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.
Product: Core → Mozilla Application Suite
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)

You need to log in before you can comment on or make changes to this bug.