Closed Bug 59078 Opened 24 years ago Closed 23 years ago

desktop integration opens with two windows

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: Matti, Assigned: law)

References

Details

(Whiteboard: win32-registry[adt3])

Attachments

(2 files, 1 obsolete file)

Export of htmlfile\shell\open
(deleted), text/plain
Details
added suggested ::RegCloseKey call
(deleted), patch
law
: review+
bugzilla
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
If you have a filetype linked with mozilla (.gif or .jpg) and you open
this file with mozilla (mozilla closed before), mozilla
shows the image and additionally open a second window with
the "Home Page" (selected in Preferences/Navigator).

I think mozilla should only open 1 window with the image and
not the second window.

WIN2k, build 2000110120 trunk
WFM on Linux 11/03 build, mozilla opens only 1 window with the image.



I forgot something :
I have a local .html File as Home-Page.
confirming win98 trunk 2000110304, cc law per blake
Assignee: asa → don
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
*** Bug 62410 has been marked as a duplicate of this bug. ***
Marking bug 62212 as a dup of this, but the summary there is better than the 
one here (IMHO) suggest this summary altered to:
'Desktop integration opens with two windows'

*** Bug 62212 has been marked as a duplicate of this bug. ***
Changing summary from
'open file (.gif) with mozilla, the "Home-Page" loaded additionally'
Summary: open file (.gif) with mozilla, the "Home-Page" loaded additionally → desktop integration opens with two windows
*** Bug 62989 has been marked as a duplicate of this bug. ***
Is this because the DDE interface always opens new windows?
Not exactly.  There is some mystery here because we have to guess as to the
behavior of the Windows Explorer/desktop.shell.  When you double click, Windows
seems to try to use DDE (if so indicated in the registry settings for the file
type).  If that fails, it then launches the app (using the shell/open registry
setting).  It then seems to again try to talk DDE to that application.

The net effect is that we open (with a browser window), and then get a DDE
request that seems to tell us to open another browser window.

The mystery surrounds that last step, I think.  When I was implementing this, I
found that my debug code (which happened to be on NT) worked fundamentally
differently than the optimized builds (that I typically ran on Win98).  My
theory at one time was that the shell would not attempt the second DDE request
if the application that started was a "windows console" application.

But then I saw behavior that didn't fit that theory.  My current theory is that
it is somehow timing dependent.  There is a period of time where we'll be
started but not yet fielding DDE requests.  That might have something to do with it.

The other thing is that sometimes, you get a Windows alert telling you it
couldn't open the file/application.  That seems to result from some failure in
the (second?) DDE request.  This might be related to the fact that we get two
windows.

There is also the related problem whereby certain other applications effectively
block the DDEConnect request we issue internally when a second instance of the
process is started.  That problem involves much of the same DDE and startup code.

I plan to try to figure this out at some point, although I do not relish having
to do so.  I hope it isn't the case that the only way to make it work is to use
some MFC-generating "wizard" to write the code.
*** Bug 62212 has been marked as a duplicate of this bug. ***
Attached file Export of htmlfile\shell\open (deleted) — 

    
    

    
  
I think our registration should mirror ie's. IE's obviously works <ok maybe it 
isn't obvious, but it does work, and they new what they were doing when they 
did it>

Attachment.

The result unfortunately is that we need a commandline like -nohome that 
basically creates a hidden window loop and waits for a dde message.

    
    

    
  
nav triage team:

Nice to fix, but we won't hold up beta1 for this, especially since it 
might involve some DDE fun. Marking nsbeta1-
Keywords: nsbeta1-

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Please add Win98 to OS.

    
    

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

    
    

    
  
this bug has more than 10 dupes adding the mostfreq keyword
Keywords: mostfreq

    
    

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

    
    

    
  
One workaround that doesn't involve the use of special keywords is to rely on 
Mozilla's DDE, i.e. don't use Windows Explorer DDE. Of course this assumes that 
all Mozilla's command-line options work in DDE, which they don't. Additionally 
while you're at it fix Mozilla so that it opens a window(s) as per startup 
prefs on the existing Mozilla session if no command line is specified :-)

    
    

    
  
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future

    
    

    
  
I've experienced the same problem with my image viewer application that I'm
writing. My solution was to completly ignore DDE and accept the file name (or
URL in this case) and send it through a private communication channel that can't
be blocked by the malfunction of other applications :
   I'm using a very special window class name for the main frame (a GUID). The
newly opened application search all top-level windows for the existens of a
window of this class (through EnumWindows). If it found one, it sends the file
name or URL to that window and exit.

Maybe this can help. (It should oalso solve the problems where mozilla won't
start because another application is marked as "blocking" in the task manager)

    
    

    
  
Maybe forget the DDE.  It doesn't/never really works anyway.  Even Microsoft had
to fudge things to get around problems with it in Macros inside Excel and Word.
 Surely that proves that it's just another worthless/badly implemented protocol
of theirs.  Better luck next time.  Besides do the builds for the other OS's
have to have two types of calls?

    
    

    
  
seems fixed, i used to see this but...
worksforme on windows cvs 2001041605

    
    

    
  
Also works for me in 2001041704.  I have not tested that in a while, as I
usually use ACDSee for .jpg and .gif files, but I do remember that behaviour in
earlier builds.  As Ferdinand said, might be fixed.

    
    

    
  
One of the best tests for this is to have someone send you a link with ICQ, and
upon clicking that link, if it open only one webshell instance, you're gold ;-)

    
    

    
  
Build 2001041704:

Now it seems like what worked in Mozilla 0.8.1 and Netscape 6 doesn't work in 
the newest daily.  Prior to the current build, my code would perform a DDE Open 
with a service name of "Mozilla" ("Netscape6", for NS6) and a Topic 
of "WWW_OpenURL". After which I could execute a macro of "-
url 'http://www.mozilla.org/'" and both Mozilla and Netscape 6 would browse to 
the specified URL, albiet, in a different window.

Using the same code, the ExecuteMacro call still returns true, but the browser 
does not navigate at all.  It just sits there all dumbfounded.

I even tried the old 4.x way using RequestData and a DDE message 
of "http://www.mozilla.org/,,,0x1", but that was a no-go also.



    
    

    
  
> Using the same code, the ExecuteMacro call still returns true, but the browser 
> does not navigate at all.  It just sits there all dumbfounded.

I hope that I'm not being redundant, but I thought I'd give share my situation.
I regularly use the daily builds on Win2k and, for several days now, clicking on
urls in my email client does nothing (clicking on urls from icq doesn't work
either). Normally, I'd expect Mozilla to load the url -- hopefully in an
existing browser window, but even loading it in a new browser window would be
better than nothing ;). I would have filed a bug report for this, but I wasn't
sure if this behavior was covered by this bug report. 

Bradley, when you made your remark, are we describing the same phenomenon?


    
    

    
  
bug 71895 caused this regression, and is probably the better place to discuss 
the recent issues.
Depends on: 71895

    
    

    
  
This 1 is back for me, i suppose it has to do with bug 50424 being fixed.
using cvs 2001042005 on winMe

    
    

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

    
    

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

    
    

    
  
Still opens a new window in v0.9 milestone.

    
    

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

    
    

    
  
Ferdinand mentioned he thought this had to do with bug 50424 being fixed.  FYI,
I just reopened that bug because it too has regressed for me in build
2001051208.  I think this bug, 50424, and 71895 may all be different parts of
this elephant.

    
    

    
  
removing nsbeta1-, so as to reconsider for mozilla0.9.2. 
Keywords: nsbeta1- → nsbeta1

    
    

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

    
    

    
  
Now law@netscape.com has fixed bug 53952 should DDE be removed from the desktop
integration so that Mozilla's own IPC is used for this? Mozilla's check for a
previous instance seems to be pretty fast.

    
    

    
  
adding back to 0.9.2 radar. 
Assignee: vishy → law
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla0.9.2

    
    

    
  
moving Windows Integration [formerly Desktop Integration] bugs to PaulW as qa
contact.
QA Contact: sairuh → paw

    
    

    
  
See also bug 58848.  This could well be the same problem.
Whiteboard: no eta

    
    

    
  
nav triage team:

Not a mozilla0.9.2 stopper, moving to mozilla0.9.3

Target Milestone: mozilla0.9.2 → mozilla0.9.3

    
    

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

    
    

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

    
    

    
  
Has anyone tried this with multiple profiles activated? I noticed that if I
tried to load a local file with multiple profiles I'd get the Profiles screen,
AND a window with the file loaded. 

The interesting part is that the opened window had no preference or profile
information. No mail accounts, Classic Skin, Default Prefs, etc. 

This is definately a confusing thing. I don't know whether it still happens as I
cant check that machine for a little while, but I remember it happening once or
twice.

    
    

    
  
What you see with multiple profiles is bug 79471.

    
    

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

    
    

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

    
    

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

    
    

    
  
we think that this bug has been fixed by a combination of other bugs already 
getting fixed. Can QA verify please? thanks, Vishy

    
    

    
  
This seem to be fixed with win2k build 20010622.. (CVS opt)

    
    

    
  
Build 2001062204, win98, win32-talkback, still does not work for me.
Tried opening URL from Eudora 5.1: two windows
opening Internet Shortcut from the desktop: two windows

The URL that was opened was the same in both cases:
http://bugzilla.mozilla.org/show_bug.cgi?id=59078


    
    

    
  
Hmm... I'm running Build 2001062204 on Windows 2000(downloaded via
mozilla-Win32-installer.exe) and it is still not working. I can double-click on
an html file or type http://somesite in the Windows Run command and get the same
result: two windows, one correct, one blank.

    
    

    
  
Does anyone have the problem that in the first window (from two opened) you 
cannot load in any URL writing it in URL bar - it reloads the previous page?

    
    

    
  
Vishy: This bug is not fixed.  I assume the checkin for 58848 is among those you
believe may help this bug.  Using 2001062104 on win2k, any html *file* I double
click opens two browsers (assuming no moz is open, including no -turbo).  Any
link in Outlook 2k or XP opens two browsers.  Any link in Word XP or Excel XP
opens *IE*.  On another machine using Word/Excel 2k, we get two browsers.  A
link in WordPerfect gets us *one* browser and in many other apps after the 58848
fix I also get one browser.  Moz was uninstalled/reinstalled for these tests.

It seems to me there are several bugs describing double open behavior.  Perhaps
it would make sense to consolidate them, assuming a common cause?  Btw, most of
our users still have NS4.73 and don't have any of these problems.  Does NS4's
approach offer any value?

Eugene: I get exactly that behavior.  Haven't filed a bug for it because I don't
know how to describe it yet.

    
    

    
  
I reduced my bandwidth to near zero to watch each step of this bug, and here's
what I found:
1. One window has barber pole load indicator, URL bar
2. The other window has status bar and actually loads the page
3. Both windows have active throbbers
4. Eventually both windows have load indicator and page title
5. The one with URL bar loads page first
6. The other window may or may not load the page, URL bar..
7. ..if not it will load the page once you enter a different URL and
8. ..you cannot load a different URL in this window.


Keywords: 4xp, 
          
            mozilla0.9.2

    
    

    
  
Adding myself to CC list...

    
    

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

    
    

    
  
Eugene,

Yes, I do occasionally see your problem. (Where the first window opened will
only re-load the current page upon typing in a new URL). Bug 82112 is along
these lines. 
Blocks: 82112

    
    

    
  
nav triage team:

Moving out to mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
    

    
  
In the desktop integration part of Mozilla, couldn't it just *not* enable the
DDE part?    When DDE is disabled, this bug disappears.

Or does mozilla use DDE for certain things?

    
    

    
  
Netscape has always used the wrong DDE settings.
Either put the command line in the open OR in the ddeexec but NOT both.
As Mozilla's IPC is better than DDE we should use the command line method.

    
    

    
  
nav triage: reassigning to pchen.
Assignee: law → pchen

    
    

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

    
    

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

    
  
Whiteboard: no eta

    
    

    
  
Ok, I think the fix for 58848 should've fixed this problem. However, after
talking to Bill Law this morning, I think we've thought about a case where you
still might see two windows pop up. The code to set the ddeexec keys to blank
should solve this problem. However, according to Bill, if you don't check the
corresponding prefs for the specific protocols or file types (e.g. http or
.html) (or don't have windows integration "on" at all?), then at startup Mozilla
will just ignore those settings and won't set the corresponding ddeexec keys to
blank.

This should work if you used the installer as opposed to the .zip archive.
According to Bill, the installer calls mozilla with '-install' which should set
the ddeexec keys to blank. There is also this reset() stuff, but I think we will
have the blank keys in effect while mozilla is running.

The Office 2000 opening two windows bug is bugzilla 88083.

    
    

    
  
pchen: I'm not sure what the upshot of your last comment is--I read you to be
saying that you think one of three things (or combination ;-): that the fix to
58848 has fixed this (was there a fix to that bug?); that if the installer is
run the "right" way Moz will "take care of it"; if the "right things" are
checked in prefs, all will be good.  It could be I completely misunderstand, so
I appologize in advance for whatever nutso stuff I'm about to say:

- 58848 fixed nothing for me.  Uninstalling ns4.7x got rid of *some* double open
behavior in office 2000 apps.

- I *always* install from the installer, not the zip.  

- I have toyed with every combination of file type and protocol setting, none
that I've found stops the double open behavior when I double click an HTML from
the file system.

There's other stuff, too.  I noted recently that when I clicked a link in a mail
sent from my citibank account (ending with .dci, I think), I got two browsers
even though a normal html from Outlook XP typically gives me just one.  Again, I
achieved this by uninstalling ns4.7x.
It's excellent to see this is being explored again--this whole area is what
prevents us from installing NS6.1 around our building.


    
    

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

    
    

    
  
are bug 95573 and dup bug 95926 related to this one?
 

    
    

    
  
Pchen - Are we gonna get to this one for eMojo? If we want this, please mark as
nsbranch+.

    
    

    
  
Here's an update on what I've been able to figure out recently.  First,
http/.html links work fine for me on Win2K.  So distinguishing what makes it
fail is a little tricky.

I did investigate at length the problem with Office2K links (see bug 88083).  In
that particular case (assuming that it wasn't something else that also triggered
the problem on the machine where I did my Office2K debugging), it appears that
Office2K (or the shell APIs it uses) will issue requests using both the "http
protocol" registry entries *and* the ".html file type" entries.  It uses the
latter only if there are any subkeys/values under shell/open/ddeexec.

In other words, blanking the default value under shell/open/ddeexec (per bug
58848, I think it was) is not sufficient in this particular situation.  We must
go further and remove the subkeys (Application and Topic).  I'm working on code
that does that; it happens to overlap with the code I'm writing to fix bug 97813
and that ones proving complicated, as well.

My theory is that clearing the ddeexec key entirely will likely clear up similar
problems in other scenarios (aside from Office2K).  Anybody having problem could
try verifying that by manually removing that subkey using regedit.

    
    

    
  
Noticed a problem in the past week or so..
Filed bug 98965  (Clicking URL in another app causes mozilla to go to blank page)
Not sure if it's related or not to this bug.

    
    

    
  
I don't think Bill will have a fix ready for 0.9.4, marking nsBranch and
mozilla0.9.5
Keywords: nsbranch
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
  
Blocks: 99227

    
    

    
  
I don't think this is worth the risk of a complicated fix at this point, and
Bill is overloaded anyway. nsbranch-/096
Keywords: nsbranch → nsbranch-
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
    

    
  
er, ->law
Assignee: pchen → law

    
    

    
  
I performed the patch (.INF) for 89534 and found that I only get one window
opened now.

    
    

    
  
I'm using Mozilla build 2001092208 on Windows 2000 SP2 on PC and when I try to
open an URL from Star > Run... the page I enter opens normaly in a new windows
but I also get an error dialog that has URL for title and reads: "Cannot find
the file "URL (the same as in title)" (or one of its components). Make sure the
path and filename are correct and that all required libraries are available.".
I hope this gets fixed ASAP.

    
    

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

    
    

    
  
Jure:

it only throws the error from the start->run when typing a full URL say
http://www.anydotcom.com - of course there is an error, its MS windows problem.
run command is not made for the http://  it is not an address bar!!!!  

Not a Mozilla problem, has nothing to do with this bug.

    
    

    
  
I guess the scope of this bug is within a word doc (an office app document) as a
link http://www.anyurlhere.com  right?

    
    

    
  
Start -> Run -> http://<anything> works for me fine.     Of course, I do have
DDE disabled.

    
    

    
  
OK, cuz, thanks for the info. But if I remember correctly if Internet Explorer
is set to handle the links then I get no error message. I tried with Opera 5 and
I also don't get that error message. So it can be set in that way you don't get
the wrror message when Mozilla is default browser.

    
    

    
  
I too saw this behaviour.

I applied the patch from bug 89534, and downloaded the latest build 2001100103.

Now I cannot get to any https site!!


    
    

    
  
Whoops, forgot to mention that I am on Win2K and that I added myself to the CC list.

    
    

    
  
Disabling DDE for various file extensions awhile back fixed this for me too 
(0.9.3 Win2k).

    
    

    
  
Moving this to match most other bugs like this which I'm targetting for 
mozilla0.9.7.
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
    

    
  
after reading this whole stuff through, i played around a little and can tell
you what works for me:

HKEY_CLASSES_ROOT
+ ...
+ shell
  + open
    + command
    + ddexec
      + Application
      + Topic

I removed the key "Application" because the default value was "IExplore". just
removed the whole key. that's it. no double windows anymore. in all cases i
encountered them. the worst thing was in ICQ. i just tripple-checked it.
removing  this key eliminates my problems. and i've ALWAYS before installed
mozilla using the installer, not the zip. my system is Win2K, btw. i just made
some tests, and found everything working now!
* ICQ
* .html-files* Word2k
* Start->Run: http://...

that's all for me :-)


    
    

    
  
> I removed the key "Application" because the default value was "IExplore". 
> that's all for me :-)

Well, I have tried it (although my Application key contained simply the word
"Folders") and nothing has changed. I use Outlook as a mail client and when I
click on a link the result is always 2 Mozilla windows with the same URL.
My opsystem is W2K and I use mozilla 0.9.5 (Build 2001101117).
So it is not the ultimate solution. :(


    
    

    
  
Some explanation to the application key:

The DDE Application (mozilla) must register an atom and answer to an
DDE_INITIATE message when this atom number (atom tables are string lookup
tables) is specified.

The windows explorer registeres an atom with the name stored in the registry
under "DDE\Application" and tries to initiate an DDE communications. If the
program (mozilla) doesn't response to this call a new instance is created. Maybe
a new dde communication is initiated but I don't know it for sure.

If you want to use DDE you must not add the URL to the path. And don't open a
new browser window if the command line caontains /DDE as a parameter. But this
doesn't work with mozilla's turbo mode if it doesn't response to the atom in the
registry.

The simpliest way to solve this is to disable DDE (by deleting the tree in the
registry and recreating it without DDE) and to use the mozilla intern
interprocess communication. (which sould be played directly in the mozilla.exe
before loading too much dlls to improve the reaction spped of the application).

    
    

    
  
To the registry hint: one important thing was missing: the ddexec part under the
keys of the needed protocols should be deleted. E.g. for me deleting DDE under
http and https finally solved the problem. Now I have no problems with Outlook 2000.

HKEY_CLASSES_ROOT
+ http or https
  + shell
    + open
      + command
      + ddexec -> delete this
        + Application
        + Topic

Last time I tried to delete the [HKEY_CLASSES_ROOT\Shell\shell\open\ddeexec] key
(unfortunatelly it exists as well), and it is no suprise it has not worked. 
Although this solution is implicitly explained in the lots of comments to this
bug, perhaps it is useful to explain it explicitly.


    
  
Blocks: 107067

    
  
Keywords: nsbranch-

    
    

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

    
    

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

    
    

    
  
Resetting target milestone for all "window integration" bugs to mozilla0.9.8.  
I'm working on performance and won't get to that till next milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.8

    
    

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

    
    

    
  
there is a chance that this bug is fixed now.. thru way of another bug.  Dont
know the # right off the bat.

    
    

    
  
Still a problem in 0.9.7

I fixed it on my W2k machine by editing the file type association through
windows explorer.

Tools > Folder Options > File Type > URL:HyperText Transfer Protocol > Advanced
> Edit 'open'

and deleting the DDE information and unchecking the 'Use DDE' box

repeat for other protocolls (if applicable) used with moz such as

URL:HyperText Transfer Protocol with Privacy
URL:MailTo Protocol
URL:News Protocol
URL:File Transfer Protocol

Mozilla prefs should do this automatically, but I don't know the code base well
enough to make the changes myself

    
    

    
  
The fix reported by Michael Crusoe works on my Win 2K machine. It also fixes the 
second part of the problem where clicking on an html file in explorer failed to 
load the file into Mozilla. So this appears to be an installation problem.

    
    

    
  
this is a windows bug, to get around it:

open My Computer
Tools -> Folder Options...
click the File Types tab
find .HTM and .HTML, or any other file type or protocol you use mozilla to open,
and change them all as follows:

select it
click "Advanced"
click "Edit" (for the "open" action -- "edit" too if its there)
UN-check "Use DDE"

and do the same for "HTTP Protocol", and anything else you open with Mozilla.


this worked for Windows ME (Win9x Mozilla build 2001122803), no clue if its
"THE" fix though. it also got rid of something else that I almost reported as a
bug: when I opened shortcuts (with "Use DDE" checked), it gave an error that it
can't find the website (even though it loaded it).

    
    

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

    
    

    
  
the bug I was refering to is bug 92156 which fixed some problem with opening in
new window.  where the description is:

'DDE: WWW_OpenURL Should Open Doc in Existing Window, Not A New One', which
doesn't  I guess, quite sound like the problem here.  

regarding this bug report: Maybe the fix for that didn't apply to all types of
files that mozilla opens.  Just modified the html ones?  Bill, care to comment?

    
    

    
  
I think there's more fun to be had there.

Every month a get a credit card statement from Citibank, the link has an
extension of .dci.  I noted a long while ago that I get two Moz when I click
that link in Outlook xp.  Most other links, though, only summon *one* window;
this is also true for links with no extension.  My profile is set to start with
about:blank and quicklaunch is on.

Now, on my XP machine, I normal "expected" behavior.  I've not been able to
install a newer Moz to the older machine today.  Besides win2k and the moz
version diff, the older machine had once had NS4 installed while the XP box has
never seen NS4.  I had found at one point that removing NS4 made Moz' desktop
integration behave better.



    
    

    
  
Not getting to this, either.
Target Milestone: mozilla0.9.8 → mozilla0.9.9

    
  
Whiteboard: win32-registry

    
    

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

    
    

    
  
Lining up bug 69372 behind this one
Blocks: 69372
No longer blocks: 99227, 107067
No longer depends on: 71895

    
  
No longer blocks: 69372

    
  
Blocks: 69372

    
  
Blocks: 88083

    
  
Blocks: 89534

    
  
Blocks: 90794

    
  
Blocks: 92527

    
  
Blocks: 92731

    
  
Blocks: 95573

    
  
Blocks: 95943

    
  
Blocks: 97765

    
  
Blocks: 98965

    
  
Blocks: 120969

    
    

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

    
    

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

    
  
Blocks: 58770

    
    

    
  
I may be restating something that's already been said, but 

I just realized that we don't associate files with the standard "htmlfile"
class.  We make our own "MozillaHTML" entry under HKEY_CLASSES_ROOT.  We also
make MozillaXML, MozillaPNG, MozillaXUL, MozillaMNG... why?  We should use the
existing htmlfile, xmlfile, pngfile, xulfile, mngfile (this last two may not
exist), etc.

Once I figured out the MozillaHTML problem, I went in and deleted the "ddeexec"
key entirely under MozillaHTML\shell\open.  Local files now open properly for
me.  See my comments in bug 58803.  I think this is another key that we should
delete the "ddeexec" subkey from under htmlfile\shell\open, once we get rid of
MozillaHTML.

    
    

    
  
Argh! I meant bug 88083, not 58803 - sorry for the spam!

    
    

    
  
Still not solved in 0.9.8 (2002020406).

Strange thing is that ico-files, when double clicked are displayed properly in
exactly one (new) window. Other files, when they are double clicked, are not
displayed at all, but instead my homepage is displayed (in one new window).
Last, when using powerpoint with a picture linked to some url, clicking that
picture opens two windows, both displaying the same content (which is not local,
but from another server).
All this under Windows2000.

    
  
Keywords: nsbeta1

    
    

    
  
nsbeta1+ per Nav triage team
Keywords: nsbeta1 → nsbeta1+

    
    

    
  
Working on this stuff next.
Target Milestone: mozilla0.9.9 → mozilla1.0
QA Contact: paw → tpreston

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch, v1.0 (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  
patch to fix this bug and some others (bug 58770, ?)

The essence of this patch is to completely remove the "ddeexec" registry subkey
for file types and protocols that we're handling.  We haven't relied on DDE
support to handle this sort of thing for some time and leaving bogus entries in
the registry causes a number of difficulties.

That code is consists of:

- a new deleteKey() function that deletes a given registry subkey by applying
itself recursively to any subkeys under the key (this code is based on info in
the MS knowledge base article Q142491).
- a call to this routine is added to the function DDERegistryEntry::set, which
is called when a the "ddeexec" entry needs to be modified.

To facilitate undoing this operation from DDERegistryEntry::reset (when the
user elects to no longer have Mozilla handle a given file type or protocol),
some additional code is added:
- We add a new "activate" data member to DDERegistryEntry to save the user's
setting for the NoActivateHandler value under the ddeexec subkey.
- because that entry is usually blank, I had to tweak some of the
RegistryEntry/SavedRegistryEntry infrastructure to properly distinguish between
missing registry entries and empty ones.

Bottom line: We save the following ddeexec registry entries when we take over a
file type or protocol:
  ddeexec/@
  ddeexec/NoActivateHandler
  ddeexec/Application/@
  ddeexec/Topic/@
(where "@" means the "default" value under a given subkey).

After applying this patch, I've verified the registry entries after taking over
a file type/protocol, and, after restoring them.  I've verified that all 3 of
these work OK when Mozilla handles http:
a. Double-click on an internet shortcut on the desktop
b. Click on a link in an Outlook mail message
c. Click on a link in a Word document

One note: To be sure that the registry is properly "cleaned up" it might be a
good idea to go to Preferences/Advanced/System and uncheck all the options
using your current installation, then install the update, then go in and check
the file types and protocols you want Mozilla to handle.

    
  
Whiteboard: win32-registry → win32-registry[adt3]

    
    

    
  
Comment on attachment 73316 [details] [diff] [review]
patch, v1.0

r=sgehani

        Attachment #73316 -
        Flags: review+

    
    

    
  
typo in patch:

+// We don't try to save everything, though.  We do save the know useful info
+// under the ddeexec subkey:

know -> known



    
    

    
  
"One note: To be sure that the registry is properly "cleaned up" it might be a
good idea to go to Preferences/Advanced/System and uncheck all the options
using your current installation, then install the update, then go in and check
the file types and protocols you want Mozilla to handle."

What does that mean for end users?

The code looks okay.  Is there anyone who's really knowledgeable about Windows
DDE/registry issues (besides you) that could r=?

    
    

    
  
"end users" aren't subject to the same issues because the installer ensures that
previous installations are properly removed.  My concern was people that install
from .zip files and might end up with saved registry entries from the old scheme
with code that expects them to match the new scheme.  I didn't try to puzzle out
what would actually happen; it's likely to be harmless in any case.

If I could find somebody willing to claim expertise in this area, I'd have given
them the bugs long ago :-).  Maybe Sean Su would be willing to render a verdict.
 I'll email him.

    
    

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

    
    

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

    
    

    
  
Sean can't do it.  We have to wait or go with it based just on faith in me and 
Samir, I guess.

    
    

    
  
Blake,

I think rdayal knows registry stuff, as he's played with simple Mapi;

    
    

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

    
    

    
  
Comment on attachment 73316 [details] [diff] [review]
patch, v1.0

It seems to me that the new function:

static DWORD deleteKey( HKEY baseKey, const char *keyName )

should be calling ::RegCloseKey() for each key it deletes.  Apart from that
(and the "know"->"known" typo in the comments already mentioned) the patch
looks good to me (fwiw :)

    
    

    
  
Good catch, thank you.

I have inserted a "::RegCloseKey(key)" call at the close of the while-loop in
that function.

    
    

    
  


  

        Attachment #73316 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 76430 [details] [diff] [review]
added suggested ::RegCloseKey call

applying r=sgehani that was provided for prior version

        Attachment #76430 -
        Flags: review+

    
    

    
  
I have applied the new patch and performed a fair bit of testing.  This now
seems to work perfectly.  Toggling between IE and Mozilla as my default browser
is perfect.  MS Office, Outlook etc all correctly display the link *once* in the
default browser.

De-selecting Mozilla as the default seems to restore IE just fine - eg,
selecting a link in Outlook just after de-selecting Mozilla as the default will
correctly start IE with the link.  However, IE will tell you it is not the
default browser (even though it was just started as the default browser!)  I
don't see this as a problem - you just answer "yes, I do now want IE to be the
default"

The patch has 2 reviews (including mine), it is a pretty in-your-face bug for
many Windows users, and has lots of dupes and deps.  I think we should go for
sr/a and get this checked in ASAP!

    
    

    
  
Mark: What happens when you click an *ftp* link in Outlook?  I reported (in one
of the related bugs) recently that while HTTP links correctly show Moz, FTP
links show IE.  *All* the protocols and file types that Moz claims to know are
checked *on* in my preferences.  This is Win XP, latest trunk nightly, NS 4.x
never installed on this machine.  Thanks.

    
    

    
  
I agree with Mark - this really needs to be in 1.0 !

    
    

    
  
When clicking on an URL in my MUA (Outlook 2K in W98), it opens two Mozilla
(0.9.9 2002031104) windows with that URL.
Keywords: patch, 
          
            review

    
    

    
  
> Mark: What happens when you click an *ftp* link in Outlook?

Works for me - finally!

I did see some very strange behaviour - including ftp links behaving strangely,
and Mozilla not always setting itself up as the default handler correctly.  This
behaviour persisted with and without the patch.

However, once I deleted the HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla key, everything
worked fine after.  I suspect that somehow the old "saved" registry keys got out
of synch, but have not been able to repro.  So I think this patch is still
perfect for this bug :)


    
    

    
  
Mark I can confirm that that happens quite a bit with several builds and
directories installed.. and usually goes away after deleting the 2 mozilla and
the 2 mozilla.org registry folders, and installing a new build in a new
directory gets me going again.  

Bill looks like we need a sr= and a= now.. :) yippie!   




    
    

    
  
Comment on attachment 76430 [details] [diff] [review]
added suggested ::RegCloseKey call

sr=blake

        Attachment #76430 -
        Flags: superreview+

    
    

    
  
QA, related to Mark's last comment, but not a problem/issue with the patch for
this bug problem:

Mark, I believe to what you are refering to is Simple Mapi, just like Mail/News
setting itself as the default windows app in Control Panel > Internet Options. 
And Mozilla as a seperate app then Netscape.  But If you have multiple Mozilla
builds this can confuse you when it comes to opening Moz for files it handles &
debuging this issue.  

As I found out once with debuging QL and multiple profiles; I was trying to
figure out why I was thinking two builds were running at the same time, using
seperate profiles, but weren't and they were changing the registry keys each
time I ran a different build I was using, then trying to debug web page layouts
from one build to the next while the web-designers were actually making changes
to those same pages add that to the fact at the time bugzilla didn't allow easy
uploading of site source code..   

all in all, at the time it really through me for a loop.. trying to figure out
what the heck was going on.. much like you are seeing in your comment.

so with that.. like you noted, with or without the patch it is seperate and as I
noted, it should be gone if following my other comment I just made.

    
    

    
  
Comment on attachment 76430 [details] [diff] [review]
added suggested ::RegCloseKey call

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

        Attachment #76430 -
        Flags: approval+

    
    

    
  
Looking for ADT approval.

This fix is very low risk.
Keywords: patch, 
          
            qawanted, 
          
            review → adt1.0.0

    
    

    
  
Agree that this seems like low risk, but its not severe enough to take any
amount of risk at this time = adt1.0.0-
Keywords: adt1.0.0 → adt1.0.0-

    
    

    
  
Jaime: do you mean for rc1 or for 1.0 or any forthcoming Netscapes?  If not for
rc1, I respectfully disagree and would echo others: from the local experiences I
see where NS' reputation was near destroyed by 6, it is imperitive that you
respect Windows norms by integrating well.  Opening two windows in win2k, *ever*
opening IE when a user expects Netscape, showing the IE icon on files that are
thought to associate with Moz/NS--all lead to questions and support calls.  The
tech support people are already indifferent at best, these behaviors confuse and
even antagonize users.  Sorry for the evangelism.

    
    

    
  
Yeah, it's an important bug to fix. What I don't understand is the difference
between nsbeta1+ and adt1.0.0-. Whatever. It's cool.

    
    

    
  
I fully agree with #144 and #145. While this may seem a minor problem here, in
reality it can really ruin the user's experience. 

    
    

    
  
Removing adt- to request re-consideration.  This is low-risk and high-profile. 
It's on the most-frequent bugs list.  This will be a common problem for people
switching over from IE, and it needs to be corrected for 1.0.
Keywords: adt1.0.0- → adt1.0.0

    
    

    
  
needed for RC1
Blocks: 134771
Keywords: mozilla1.0+

    
    

    
  
adt1.0.0+ (on ADT's behalf) approval for checkin to 1.0.
Keywords: adt1.0.0 → adt1.0.0+

    
    

    
  
Fix checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Verified fixed win XP build 2002041011, linux build 2002041109 and Mac OS X
build 2002041011
Status: RESOLVED → VERIFIED

    
    

    
  
Thanks for everyone's work on this set of bugs--this may now be a support issue
rather than a setup or behavior issue.  I'll describe what's happening then you
can tell me where this stuff should be discussed, if not here.

I'm still having issues on two XP machines.  It may be I need to do some
registry work beyond uninstalling moz and removing its keys.

On one XP machine (where NS has never been installed):
- An FTP link in Outlook opens IE, not Moz.
- Start/run mailto:anybody@somehost.somedomain opens Outlook, not Moz mail
though I answered yes to Moz' question about being the mail handler.  mailto in
help or some some custom apps I'm writing (where I use ShellExcecute) open
Outlook, not Moz.

On another XP machine (where NS6.21 had been installed)
- the Mozilla.org.../desktop key is full of paths to netscape even though
netscape is uninstalled
- mailto: links open outlook express though Internet settings shows moz as the
mail handling program
- the NS icon is shown in win explorer for html and the other file types that
moz is handling--but Moz does open them when they're clicked.
- Start/run mailto:anybody@somehost.somedomain opens OE not Moz mail though I
answered yes to Moz' question about being the mail handler

On both machines, Internet settions shows OE as the news handler.

    
    

    
  
I suggest you open a new bug specifically for any Windows XP issues (please
search for existing ones first :).  Please CC me - I have an XP CD here, and
will get it installed over the next few days.

Re "mailto:" - there may be existing bugs with this protocol - indeed I seem to
see a few.  I haven't looked into these though, and these aren't really covered
in this bug.  

Re "news:" and other misc protocols - I believe this is covered in bug 94302.

Re Uninstall leaving "turds" - also not this bug, but quite possibly in another.
 If not, add it.  Unlikely to be XP specific.

    
    

    
  
removing item for this bug from the release notes since the bug is marked
fixed. If this is in error, please make a note in the release notes bug for
the current milestone.

    
    

    
  
was this fixed on the branch? (bug 147200 filed with 1.0rc3)

    
    

    
  
Works for me on the branch.

    
    

    
  
*** Bug 146294 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: