154238 - ddeexec registry subkey entries need to be set to enable full integration with Adobe Acrobat

Status: VERIFIED FIXED

(Core Graveyard :: Cmd-line Features, defect)

Description

[Bill Law]

Since NS6.1 (and equivalent Mozilla release) we have not set the Win32 registry
entries under HKEY_CLASSES_ROOT\http\shell\open\ddeexec.  As a result, some
features of Adobe Acrobat do not work correctly when Mozilla/NS are the "default
browser."

Specifically, the following are known to be broken:

1. When clicking on the Adobe-logo button on the Acrobat plugin toolbar inside
the browser, the page http://www.adobe.com/acrobat/ is opened in Internet
Explorer, rather than in Mozilla/NS.

2. When an Adobe Acrobat PDF document is being viewed within Acrobat Reader,
then clicking on a web link in the document will open in Internet Explorer,
rather than in Mozilla/NS.

3. When clickin on an html link to content of type application/vnd.fdf (e.g., at
http://acroeng.adobe.com/BrowserTestSuite/forms/testforms.html; click on the
"Test going from HTML to FDF" link in the left-hand frame, then click the
"Returns FDF that specifies a PDF" button), the resulting PDF is displayed in
Internet Explorer instead of in Mozilla/NS.  Note that this is just a special
case of 2, since the application/vnd.fdf content is handed off to the Acrobat
Reader which then opens the specified PDF using the same basic mechanism as does
clicking on a web link.

In order for Acrobat to successfully interact with Mozilla/NS in these
situations requires that we set certain entries in the registry to certain
values.  We do not set these entries because of the following:

When these entries are set, the Windows "desktop" (aka, Explorer) will attempt
to use DDE to converse with us to open Internet shortcuts or HTML files when the
user double-clicks on them (and opens them via other means).  For some reason,
if Mozilla/NS is not already running, then opening such Internet shortcuts or
files results in display of a Windows alert, informing the user that the web
location, "or one of its components," could "not be found."

As best as can be determined, this "error" (which is not really an error, since
the shortcut/file that was clicked on will be opened) occurs because starting up
Mozilla/NS takes too long and Windows erroneously concludes that something has
gone wrong.

This bug shall be used to track resolution of this issue.  We need to decide
which is the lesser of two evils, or, come up with an alternative solution to
the problem.

Comment 1

[Bill Law]

Nominating (I hope I got all the magic keywords)

Comment 2

[Bill Law]

An alternative solution (courtesy of Peter Trudelle):

Set the requisite registry entries at startup, and unset them at shutdown.  This
will avoid the issue of Windows using them when it has to launch us.  It will
enable Acrobat to sucessfully converse with us whenever we are already running
(which will hopefully be most of the time, given that we would be selected as
the default browser and are encouraging users to utilize the QuickLaunch feature).

Note that in particular, this would remedy *all* problems arising from use of
the Acrobat  plugin from within Mozilla/NS.

I am working on implementing and testing this strategy.

Comment 3

[Michael Lefevre]

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

Comment 4

[Bill Law]

Copying over keywords from duplicate Bugscape bug
(http://bugscape/show_bug.cgi?id=16574).

Comment 5

[timeless]

trudelle's suggestion is interesting but won't work if a user isn't allowed to 
edit their registry.  (Locking keys is not unreasonable. I do it because I hate 
it when apps mess with mine, and have intentionally locked some keys to stop 
them from being munged -- I haven't gotten around to locking all of the Media 
keys which i need to do became WMP keeps attacking them. There are other 
reasons keys might be locked especially in enterprise/school configurations.)

Comment 6

[sairuh (rarely reading bugmail)]

win32 integration qa -> terri

Comment 7

[Jaime Rodriguez, Jr.]

removing adt1.0.1 until there is a fix that has landed on the trunk and been
verified.

Comment 8

[K'Trina Medina]

ADDING SOME INFO FROM A BUGSCAPE DUPE

OK, here's some more DDE (Dynamic Data Exchange) bad news: we're NOT writing a
key registry key that Adobe Acrobat *relies* on to open our standard DDE-call
answering service (NSShell). If we keep this up, Adobe invokes IE all the time.
Here's more information from Adobe.  *PLEASE* *PLEASE* let's do this.

Hi Folks:

Thanks to a very astute observation by Adobe QE God Jeff Moran, I have solved
the mystery of why does Acrobat "weblinks" always open IE, no matter what the
default browser is and no matter what browsers are currently running (this is
definitely NOT the expected or designed behavior):

Not only is the Netscape 7 installer NOT writing the registry key that Acrobat
looks for the default browser, it is completely removing it if it already was
there!  

YIKES! This is very bad! The impact of this is you are forcing hundreds of
millions of Acrobats out there to launch "the other browser"!!!! (and to think I
was believing the problem was caused by some nasty trick n the latest IE
release... )

Here is an experiment:

1 - Remove all netscape and mozilla browsers from your machine. 

2 - Install Netscape 4.78 (or whatever).  Make it your default browser. 

3 - Look at the registry key:
HKEY_LOCAL_MACHINE\software\\classes\\http\\shell\\open\\ddeexec\\application
It should say "NSShell"

4 - Exit all browsers and click the weblink in the attached file.  It should
launch NS 4.78 and go to cnn.com.

5 - Exit all browsers, start IE, and click the same weblink (while NS 4.78 is
running and on some other page. ). NS 4.78 should still go to CNN.com

6 - Now install NS 7 PR1 and make it your default browser.

7 -- Check the registry key above (refresh in Regedit). Not only does NS 7
installer NOT write the registry key, it completely deletes "ddeexec" and below! 

8 -  Now for our tests. First, exit all browsers. Click the weblink. Acrobat
launches IE.

9 -- Now for the real killer test. Start Netscape 7. Click the weblink. Acrobat
launches IE and tells IE to to cnn.com! 

In other words, by removing this registry key, you are telling Acrobat to launch
the other browser, no matter what! 

Needless to say, this is the #1 critical bug to fix ASAP.   

I will need to inform our customer support folks to be on the lookout for this.
The only fix is to make NS 4.X the default browser. 

GAAWWWWWWDDDD!  I really do hate this stuff!


------- Additional Comment #3 From Peter Lubczynski 2002-06-06 14:33 -------

Wasn't there some technical reason DDE was shut off this way?


------- Additional Comment #4 From [e-mail] 2002-06-06 17:00 -------

I can confirm that step #7 occurs.  "ddeexec" and below is removed.  I did not
reproduce the tests involving weblink since this link is not provided here.


------- Additional Comment #5 From Peter Lubczynski 2002-06-06 17:16 -------

here ya go, web-link enabled PDF:
http://acroeng.adobe.com/BrowserTestSuite/weblink/weblink_more.pdf

I think you can also click on the Adobe icon in their toolbar.


------- Additional Comment #6 From [e-mail] 2002-06-13 11:17 -------

I wanted to include some additional info provided by the Adobe folks:
------------------------------------------------------------------------

Second Major Problem:  Registry Key Omitted When NS 7 Is Default Browser

When you install Netscape 7 and make it your default browser, not only does
Netscape 7 not write a critical registry key, it actually deletes it. The reason
that this was done had to do with issues of DDE with MS Word and Explorer. 

Unfortunately, the impact of this is that Acrobat will always launch Internet
Explorer, no matter what the default browser is and no matter what browser is
running! This is an extremely serious problem and will cause many customer
issues for both our companies. Quite honestly, I think we would have to remove
support of Netscape 7 if this issue is not resolved. It is that serious. 

---------------------------------------------------------------------------

This is actually very frustrating and is a critical fix.

You can easily test this:

First scenario: watch IE get launched even if nscp is set as default.
Requirements: you must have IE installed
1. open nscp
2. display a pdf within the browser
3. select the Adobe icon in the upper right of the plug-in window
 -- IE will launch and direct the user to the Adobe website

Second scenario: watch nscp not launch an additional window
Requirements: uninstall IE
Note: this is a simple test to show this failure, this particular test may not
be earth shattering in that a new window is not opened and pointing to Adobe
website, rather note that nscp is not launched: it is a deadend
1. open nscp
2. display a pdf file within the browser
3. select the Adobe icon in the upper right
Note: nothing happens, the sequence does not function. This is due to the lack
of a registry entry.


------- Additional Comment #7 From Bill Law 2002-06-25 15:28 -------

This bug is superceded by bugzilla bug 154238
(http://bugzilla.mozilla.org/show_bug.cgi?id=154238).

Comment 9

[Peter Trudelle]

Should this be resolved as a dup then?

Comment 10

[K'Trina Medina]

We're leaving this bug open. I added the comments to this bug so I can close the
bugscape bug. 

Comment 11

[Peter Trudelle]

Then should it depend on bug 154238?  Why have two independent bugs open for the
same issue?

Comment 12

[K'Trina Medina]

I completely trust your judgement if you would like to keep both open. Can we
mark dependencies between bugzilla and bugscape bugs? Let me know how you want
to go about it and I'll make the changes.

Comment 13

[Bill Law]

Attachment: Patch that sets ddeexec subkey entries while we are running

Here's the patch that does what its description says.

I'm not thrilled with it (I didn't like hacking EnsureProfile to add this
totally unrelated feature; but that was the only place I could insert the
requisite code without hacking a number of other files).  But aside from that
aesthetic issue, it is simple enough and works with no observable regressions.

There is one minor *change* in behavior (not sure it would qualify as a
regression):  when the shell uses DDE to open a new file or window, that
happens in the most-recently-used browser window, instead of opening a new
window.  Personally, I prefer that behavior.  But people's tastes might differ.


That can be remedied by tweaking the one registry entry (the one that's set to
"%1",,-1,0,,,) so that it specifies -1 for the fourth argument.

Comment 14

[Bill Law]

Something I forgot to mention: This code doesn't do anything by itself.  The 
feature is triggered by a pref named "advanced.system.supportDDEExec".

I have another patch that would add this pref to all.js and turn it on:

Index: all.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v
retrieving revision 3.389
diff -u -5 -r3.389 all.js
--- all.js      19 Jun 2002 22:20:49 -0000      3.389
+++ all.js      27 Jun 2002 20:02:27 -0000
@@ -738,5 +738,12 @@
 pref("plugin.override_internal_types", false);

 // See bug 136985.  Gives embedders a pref to hook into to show
 // a popup blocker if they choose.
 pref("browser.popups.showPopupBlocker", true);
+
+// Pref to control whether we set ddeexec subkeys for the http
+// Internet shortcut protocol if we are handling it.  These
+// subkeys will be set only while we are running (to avoid the
+// problem of Windows showing an alert when it tries to use DDE
+// and we're not already running).
+pref("advanced.system.supportDDEExec",true);

Comment 15

[Garrett Arch Blythe]

Comment on attachment 89440 [details] [diff] [review]
Patch that sets ddeexec subkey entries while we are running

r=blythe

We may want to set the "https" key as well with no additional risk, though this
is not as often used I will leave it at your discretion.

Comment 16

[Bill Law]

I don't think that's necessary.  The *real* reason we're setting those entries 
is for Acrobat to use them.  Acrobat only looks at the entries under http.  
https will still work fine, Windows Explorer will just use the 
shell\open\command to communicate with us instead of DDE.

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

What does this reg key do, and why can it only be present when the app is
running? What happens in the case (heaven forbid!) when the app crashes? 

Comment 18

[Bill Law]

re: What does this reg key do, and why can it only be present when the app is 
running?

From comment 1:

>When these entries are set, the Windows "desktop" (aka, Explorer) will attempt
>to use DDE to converse with us to open Internet shortcuts or HTML files when 
>the
>user double-clicks on them (and opens them via other means).  For some reason,
>if Mozilla/NS is not already running, then opening such Internet shortcuts or
>files results in display of a Windows alert, informing the user that the web
>location, "or one of its components," could "not be found."

Unsaid here was that everything indeed works just fine if we *are* already 
running.  So that's why we should only set the registry keys in that case.

re: What happens in the case (heaven forbid!) when the app crashes? 

Certainly nothing as bad as the crash itself :-).  The registry keys remain 
set, of course, and the user may see the bogus Windows "not found" alert one 
time (but *only* if the very next time they start Mozilla they do so by opening 
an Internet shortcut).  Once we stop normally, things will return to normal.

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 89440 [details] [diff] [review]
Patch that sets ddeexec subkey entries while we are running

sr=[e-mail]

Comment 20

[Bill Law]

fixed on trunk

Next step is to test it out and work on getting approval for branch...

Comment 21

[lmcquarr]

Awesome!  Thank you, Bill.

Comment 22

[Bill Law]

Re-opening because I screwed up this first fix.  It does not handle the case 
where the user has instructed Mozilla to handle http Internet shortcuts but 
then has allowed another browser to "steal" it away.  That happens (IE tries to 
do it each time it runs, as do we when the tables are turned).  In that case, 
we jigger the ddeexec subkeys at startup and then zap them on exit.  Oops, IE 
is broken (ironically, in the same exact way we were, prior to this fix).

Anyway, the right way to do things is very simple (conceptually, at least).  
Instead of checking whether the user *wants us* to handle http, we need to 
check whether the registry is actually set so that we *are* handling http.  The 
code is a little more verbose than that, in the typical xpcom-ish fashion.

Patch coming...

Comment 23

[Bill Law]

Attachment: Proper fix, this time

...so here it is.  I'm on the prowl for reviewer/super-reviewer (don't all run
off and hide this time...)

Comment 24

[Bill Law]

Comment on attachment 89440 [details] [diff] [review]
Patch that sets ddeexec subkey entries while we are running

Oops.  I erroneously marked this as obsolete.  It is not.  It just needs the
new one added on to make it work properly.

Comment 25

[Bill Law]

Garrett/Blake/Ben, can I beg you for another review, super-review?

Comment 26

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 89616 [details] [diff] [review]
Proper fix, this time

sr=[e-mail]

Comment 27

[Blake Ross]

Comment on attachment 89616 [details] [diff] [review]
Proper fix, this time

r=blake

Comment 28

[Bill Law]

Additional fix now checked in on trunk.

Comment 29

[chris hofmann]

Comment on attachment 89616 [details] [diff] [review]
Proper fix, this time

a=chofmann for 1.0.1 set fixed1.0.1 after checking in.

Comment 30

[Bill Law]

checked in on branch

Comment 31

[Terri Preston]

Reopening bug, this is not fixed on branch build 2002070208 (tried on a new
install and the key is not set) (also followed the instructions in comment #8
and after step 6 key is also not set)

Comment 32

[Terri Preston]

I see the same behavior using win xp trunk build 2002070304

Comment 33

[shrirang khanzode]

I agree.

Comment 34

[Simon Fraser [no longer active]]

Diff from bonsai on the branch shows a new line in all.js:
+ pref("advanced.system.supportDDEExec", true);                                   

Why is this windows-only pref going into all.js? You're penalizing the startup
time on every platform with a pref that is only used on one. winpref.js is the
correct place for this.

Comment 35

[shrirang khanzode]

this pref sets itself..after a browser restart upon installation. However, the 
browser reezes if I click on the 'A' icon in the acrobat toolbar (a new window 
launches..and the browser freezes).

testcase: http://slip.mcom.com/shrir/License.pdf

Comment 36

[Terri Preston]

Using win xp branch build 2002-07-12-08 and Adobe Acrobat 5.0 , when I:
1.Click on the adobe icon
2. It opens a nav window and goes to netscape.com
3. Then the browser freezes for a few seconds until an error dialog comes up
says: Adobe could not run the web browser. Unknown error (0)  
4. When you click okay, the browser responds again 

Comment 37

[lmcquarr]

Attachment: Simplied Test Case: Open PDF and and Click in the Middle

This is a simplified test case for the functionality that we are testing.
When you have the proper version of Acrobat installed (more later on that
version),
open this PDF file, and click on the middle of it, then Acrobat will
tell "a" browser (more later on which browser) to go to www.cnn.com.

Comment 38

[lmcquarr]

Hi Folks:

I've been buried and have missed the recent conversations.  Beth alerted me
that this fix needed to be verified.  I downloaded today's mozilla build
(2002071608), and it worked perfectly for me (THANK YOU, BILL).   I have
some notes below that should help clarify how to test this properly.  As
far as I am concerned, however, it is fixed (and Bill Law rocks!). 

Testing Notes:

0 - Install NS 7 or Mozilla and make them the default browser.  (I *did* notice
that when you run them the first time and make them the default browser, the
registry key is not set up properly ... it is only set up properly the second
time you run them.)

1 - Install Acrobat 5.1 Reader BETA!  Yes, you need an updated version of
Acrobat to test this bug.   I can get you a copy ... just ping me.

2 - Run Acrobat and open the PDF file that is in the attachment.  When
you click on the center of that page, you will test the functionality.
Note that this is a simplified test case.  The underlying functionality
is used in many places in Acrobat ... typically hidden.  This is the
simpliest test case I can find.

Expected Results with This Bug Fix
-----------------------------------

If NS 7/Mozilla is the default browser and it is running, then
Acrobat will tell NS7/Mozilla to go to www.cnn.com, which it does.

If NS7/Mozilla is the default browser but is NOT running, then
Acrobat will open Windows Internet Explorer and tell it to
go to www.cnn.com  (the DDE key is deleted now ... so we use
a default behavior).

If you have any further questions, my AIM name is LizLizMcQuarrie
(and I am back on AIM again ...)

I hope this helps! 

Comment 39

[Terri Preston]

Okay, marking fixed and adding fixed1.0.1 again, this is fixed using the new
Acrobat and win xp branch build 2002071808

Comment 40

[Eugene Savitsky]

This fix caused very annoing regression bug 155402. Please look into it.

Tnx.

Comment 41

[sairuh (rarely reading bugmail)]

rs vrfy for the trunk.