65741 - N6: error message when opening local files (gif/jpg/html) on Windows

Status: VERIFIED DUPLICATE of bug 58770

(Core Graveyard :: File Handling, defect, P2)

Description

[lchiang]

- double-click local file (.gif or .jpg or .html)

BUG: 
Netscape 6 launches with error message saying that the file (or one of its 
components) could not be found, although Netscape 6 displays the file correctly.


German Netscape M18 - Gecko/20001106



------- Additional Comments From [e-mail] 2001-01-08 05:58:23 ----

Reassigning to myself. Adding DE keyword.

Actually this happens in the US product also. It is to do with registry settings 
. This used to also happen sometimes in 4.x. What versions of windows are you 
seeing this on?




------- Additional Comments From [e-mail] 2001-01-08 06:21:32 ----

Happens on Win95/98/Me/NT/2000



------- Additional Comments From [e-mail] 2001-01-17 10:11:50 ----

Since this is not Netscape proprietary, I'm moving this bug to Bugzilla.



------- Bug moved to this database by [e-mail] 2001-01-17 10:12 -------

This bug previously known as bug 3607 at http://bugscape.netscape.com/
http://bugscape.netscape.com/show_bug.cgi?id=3607
Originally filed under the Browser product and Browser-General component.

The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here, [e-mail].
   Previous reporter was [e-mail].

Comment 1

[lchiang]

reassign to default owner.

Comment 2

[Keyser Sose]

Marking NEW.

Comment 3

[Asa Dotzler [:asa]]

reassign.

Comment 4

[Doug Turner (:dougt)]

Scott, per email, I am assigning you my MIME related bugs.  

Comment 5

[Scott MacGregor]

I'm not sure I understand the bug fully but clicking on gif and html file urls
works for me.

Comment 6

[scottputterman]

I see this too.  Go to your desktop.  Dbl click on a jpg and you will see this
problem (assuming current build handles jpgs).

Comment 7

[scottputterman]

moving to 0.9.2

Comment 8

[Scott MacGregor]

Hmm I can only seem to reproduce this on a commercial release build. My debug
mozilla build doesn't demonstrate the problem.

This is also very strange. The alert is actually coming from the OS and not from
NS6. It's a native OS alert dialog we are getting. Very odd.

Comment 9

[scottputterman]

adding PDT+

Comment 10

[Scott MacGregor]

This seems to be a problem with our DDE implementation. We aren't sending some
sort of ACK back to the OS and that's causing the OS to bring up this dialog.
Our resident DDE expert is on sabbatical so I'm reading the specs to try to
figure out what we need to do. 

Comment 11

[Scott MacGregor]

I found it! It looks like when we bring up a profile manager and then select a
profile to run with, that causes nsAppShellService::Quit() to get called. This
causes our DDE server to get unregistered. 

By a fluke, our DDE support still kind of works because of the way Bill Law is
passing events to a hidden message window. However, our server is totally DOA!
As a result, the windows shell never gets any acknowledgements back to it's DDE
requests so it throws up the error dialog. Even though we still processed the
request correctly.

I now need to figure out why selecting a profile and launching with a profile
causes nsAppshellService::Quit to get called. cc'ing ccarlen since I suspect my
patch will involve profile interaction. 

Comment 12

[Scott MacGregor]

Here's the snippet of profile code that's causing the problem:

// function : <profileSelection.js>::ExitApp();
// purpose  : halts startup process forcefully
function ExitApp()
{
  // Need to call this to stop the event loop
  var appShell =
Components.classes['@mozilla.org/appshell/appShellService;1'].getService();
  appShell = appShell.QueryInterface( Components.interfaces.nsIAppShellService);
  appShell.Quit();
}

By telling the appshell service to quit, we are telling the DDE service to shut
down. Shouldn't we only tell the appshell service to quit iff the user hit
cancel in the profile manager instead of selecting a profile and hitting okay?

Comment 13

[Conrad Carlen (not reading bugmail)]

Hah! I have a patch to get rid of that annoying appshell::quit problem on bug
86021. I found out about the ill effects of that on DDE so it's going away.

Comment 14

[Scott MacGregor]

really? That's great news Conrad. 

For now, I came up with a work around patch which moves some code out of
appshellService::Quit and into nsAppShellService::Shutdown so we don't
unregister the DDE service if Quit gets called. 

I'll post it here but it sounds like I may not need it. 

If your fix doesn't look like it's going to make the .9.2 deadline, can you let
me know so I can check in this work around? 

Comment 15

[Scott MacGregor]

Attachment: work around if conrad's changes can't make .9.2

Comment 16

[Alec Flett]

just in case conrad's fix (which got checked in last night) don't get fixed,
then sr=alecf

Comment 17

[Scott MacGregor]

Conrad's fix actually didn't fix it. I should have realized it wouldn't. Why?
because nsAppShellService::UnregisterTopMostWindow automatically calls quit when
the last top most window goes away. This of course happens when the profile
window goes away as we end up bouncing off 0 top level windows. I might be able
to use conrad's fix to make mine easier by making sure UnregisterTopMostWindow
doesn't call quit if we have a new window pending (he already has a bool for
that). Let me test that out and I'll make a new patch. 

Comment 18

[Conrad Carlen (not reading bugmail)]

From here:
http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsAppShellService.cpp#818
When the profile window is going away, mQuitOnLastWindowClosing must be false.
Is it not? Then Quit isn't called.

Comment 19

[Scott MacGregor]

actually what I'm seeing is now pretty weird. In a release build from this
morning, I get the same behavior as b4. The OS throws up a dialog saying we
couldn't locate the file even though we process the DDE request. 

However when I try the same stunt on a mozilla build I end up crashing because
we aren't getting any arguments (file we want to load) when we are processing
the DDE  execute command in our DDE callback. I'm not sure why I can't trick the
release build into crashing yet. More details soon.

Comment 20

[selmer (gone)]

6/20 is past, need new eta.  Is the workaround patch viable for 092?

Comment 21

[scottputterman]

moving to 0.9.3 and putting nsbranch keyword.

Comment 22

[Scott MacGregor]

argghhh...I found part of the problem. Bill recently checked in a fix for #58848
which cleared out the topic field in the windows registry. He was basically
trying to turn off DDE support for mozilla. I'm not sure why he was doing this
yet. I have to dig some more. But the end effect is that w/o a topic, windows
still invokes the dde executable passing in a "System" topic to us which we
don't support. So we return an error and then the OS throws up the dialog about
opening the local file. 

The fix for this bug is to back out Bill's registry changes. I'll attach the
patch that does that. This ONLY fixes it for the case where mozilla is already
running. If mozilla needs to be launched, we still get this alert dialog and
then we load the document. I believe this is because the DDE server isn't
getting started earlier enough in the load process so it can't acknowledge the
client's request before the OS times out and throws up the dialog. 

Comment 23

[Scott MacGregor]

Attachment: First part of the fix, back out the changes to winhookutils.cpp

Comment 24

[scottputterman]

moving to 0.9.4

Comment 25

[Matthias Versen [:Matti]]

*** Bug 95017 has been marked as a duplicate of this bug. ***

Comment 26

[Scott MacGregor]

triage --> .9.5

Comment 27

[benc]

qa to me:
can someone corrrect the component?

Comment 28

[Scott MacGregor]

not an emojo stopper.

Comment 29

[benc]

Lisa: I have been trying to reproduce this on Win98, and it doesn't happen to 
me with Commercial 094 20011004. Can you try this again?

Comment 30

[lchiang]

Ben - I never have seen this problem.  I moved the bug from bugscape and it's
made me the reporter.  I tried it now and I get IE to launch so I've never seen
the problem here.

ScottP - you saw this problem once.  Do you still see this problem?

Comment 31

[benc]

File handler->

This works for me, I opened some gifs and text files on Mozilla 0.9.5, Win NT 
4.

Comment 32

[scottputterman]

moving to 0.9.9.  I'm having trouble getting a newer trunk build to be my
default browser.  On an 0.9.4 based release I still see this but that doesn't
mean anything.  If someone else can verify this doesn't happen, please mark WFM.

Comment 33

[Jesse Houwing]

This seems also to be widely discussed in bug 59078

Comment 34

[benc]

-> File handling for real this time.

I'm still not seeing this anymore, in fact, all 4 windows systems I use a have 
been configured to be the default browser via double-clicking on images and 
html.

Comment 35

[scottputterman]

Adding law who I've been told might be working on this.  

Comment 36

[scottputterman]

I've been told this might be due to a problem interacting with Office 2000 on
the system.

Comment 37

[Blake Ross]

Seems like a dup of 58770 to me.

*** This bug has been marked as a duplicate of 58770 ***

Comment 38

[sairuh (rarely reading bugmail)]

marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica