25699 - DDE implementation

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[vicven]

Mozilla doesn't support the old Netscape's DDE implementation

Comment 1

[Sean Richardson]

Punting from "Architecture" product back to "Browser".

Comment 2

[leger]

Moving all open "[e-mail]" assignee bugs to "[e-mail]" to 
review.

Comment 3

[Sean Richardson]

Come to think of it, this would have to be handled at the NSPR level,
so whether it's even possible depend on what NSPR is supporting...

Comment 4

[srinivas]

NSPR supports low-level runtime facilities (see 
http://www.mozilla.org/docs/refList/refNSPR/)

This should be assigned to the browser category.

Comment 5

[Sean Richardson]

Fully understood, but if NSPR does not "do" DDE on Win32, nothing can be done
at the browser level... Since COM had replaced OLE which replaced DDE back
in the early 90's, it wouldn't surprise me to hear that the NSPR version that
Mozilla uses no longer supports DDE, using XPCOM exclusively instead. Does it? 

Booting this back to the "Browser" product, where it should have stayed.

Comment 6

[leger]

dp, your comments?

Comment 7

[Suresh Duddi (gone)]

Peter your comments ? I dont even kow who to assign this to.

Comment 8

[Peter Trudelle]

I don't think this is a *user* interface issue. The API seems browser-oriented, 
let's give Don a shot at it.

Comment 9

[verah (gone)]

Reassigning as per Don

Comment 10

[leger]

Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.

Comment 11

[Gervase Markham [:gerv]]

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

Comment 12

[don]

Move to M19.

Comment 13

[leger]

Putting on [nsbeta2-] radar. Removing [5/16].   We did as much as we need to 
support multi - instance.

Comment 14

[johng]

nav triage team:
Please explain in user language and what effect it has.
[NEED INFO]

Comment 15

[Paul Chen]

nav triage team:
if leger says handling multi-instance is all the DDE support we need, then it's outta here, nsbeta3-

Comment 16

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 17

[Barry Marshall]

Where does this bug sit?  There hasn't been any traffic on it in quite some
time.  There's a related bug on OS/2
(http://bugzilla.mozilla.org/show_bug.cgi?id=58795), so I'm just trying to
position it.

Can we retarget this?  I sure wouldn't want to wait for M19...  8-)

Comment 18

[Bill Law]

Setting milestone to Future.  There is minimal DDE support (Win32 only) and
that's all there will be for now.  We're deciding what to work on for the next
release (not sure what milestone that corresponds to) and this was one of the
things we talked about (again, Win32 only).

Our stategy will likely be to examine the existing third-party applications that
might communicate with Mozilla via DDE and decide which to support based on the
benefit to users.  Input on those kinds of questions would be appreciated.

Comment 19

[Simon Lucy]

Polling vague third parties to discover the kind of support to provide seems a
backwards way to go.  Provide the same DDE support as in Netscape 4.x and allow
topics to be extensible if possible.

Comment 20

[Gervase Markham [:gerv]]

One third party app which wishes to communicate with Mozilla via DDE is 
Arachnophilia (http://www.arachnoid.com), a web editor. It does preview in a 
browser window, and can keep using the same one using DDE (I think.)

Gerv

Comment 21

[aaronr]

There are at least a couple of big IBM customers that use DDE and Netscape 4.x.
4.x level of support at a minimum seems very reasonable.  I could possibly get
some more specifics from our customers if deemed necessary.  If Netscape 6's
DDE support is exactly that of mozilla's (but with possibly a different service
name?) I am confused why WWW_OpenURL seems to be using XTYP_EXECUTE instead of
XTYP_REQUEST like netscape 4.x did (or at least that is what the DDE sample on
developer.netscape.com uses).

Comment 22

[lmcquarr]

AHHHHH!!!  One application that definitely needs some parts of the old
NS 4 DDE interface is Adobe Acrobat!  First, let me explain what we use it
for:

Adobe Acrobat is actually a separate application than the browser, though
most users see it as part of the browser when they encounter a PDF file on
the web.    In Acrobat, we have a notion of a "weblink" -- weblinks are used
to invoke a browser (usually the default), and then tell it to go to a
particular URL.  Weblinks are extensively used "under the covers" for Acrobat
forms.

The implementation of weblinks on PC platforms is based on the old
NS 4 (spyglass) DDE interface.  NS 4 implemented most of that spyglass
interface, and Internet Explorer implements all that Acrobat needs.
Here is a description of that API:
URL: http://developer.netscape.com:80/docs/manuals/communicator/DDE/ddevb.htm
(There are also notes on the MS website as to what they implement in
IE.)

By far, the most important interface of the DDE implementation for
us is WWW_OpenURL.  We absolutely must have this in order for
Netscape 6 to be a complete platform for Adobe Acrobat.


We also use the following (but could live without them):
WWW_CancelProgress
WWW_Activate
WWW_Version
WWW_RegisterViewer
WWW_UnRegisterViewer


I am sorry that I am posting this information at such a late date.
There was a blocking bug (53347) outstanding associated with forms
support in the plug-in API that precluded me from doing any further
forms testing.  That bug was recently fixed and in the process of
doing further Acrobat forms testing, I discovered this missing functionatily
that is critical for Acrobat.

In summary:  We absolutely need the ability to tell a running browser
to go to a particular URL.  The way this was done previously on
windows platforms was by using DDE.

With IE, we can also accomplish
this with ActiveX (in addition to their minimal support of the old
spyglass DDE interface).  Using ActiveX, we can look for the running instance
of IE, get the interface to the browser, and then tell it to navigate to
the URL.

Without DDE, how can I do this with mozilla?

Comment 23

[Peter Lubczynski]

Clearing milestone to trigger re-evaluation for mozilla0.9.1 and cc:ing plugin 
people.

Comment 24

[mariusm]

We have a product that used to use DDE on Netscape4 
(more than just WWW_OpenURL). 
So I'm looking forward to see DDE on NS6/Mozilla.

Comment 25

[timeless]

We already sort of support WWW_OpenURL 
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cp
p#171

And OS/2 Supports the same stuff as Win32.

If you have a product that uses more than just the currently supported topics 
and the topics already mentioned here, please tell us which they are.  As 
always, patches are welcome.

Comment 26

[lmcquarr]

Peter Lubczynski wrote:

Liz,


I just ran DDE Spy on a version of a release build of Netscape 6.x built
Sunday night and I assure we are listening for the WW_OpenURL DDE topic. Bill
Law correct me if I'm wrong. I don't have 6.0 or 6.1 installed at home anymore
so can someone who has one of those versions please try this quick test:
1) Start DDE Spy. Setup to monitor
2) Start Netscape 6 from clicking on it's "Desktop" icon
3) Repeat, click on the Netscape 6 desktop icon again, like to open another
browser window
4) Your DDE console should have a bunch of messages.


If web links is failing, can you provide me with a testcase or bugzilla bug #
with one? Thanks!


-peter

Comment 27

[lmcquarr]

WWW_OpenURL does not work in Acrobat. Peter requested that I
run DDESpy.  Here is the output (a snipet from it).  To repo the problem,
you need Acrobat 5 and you need a special version of the
weblink plug-in for Acrobat (one that I have rigged up to support mozilla).
I can make that available when someone is ready to work on this. 

To Repo:  

1 - Install Acrobat 5 and drop my special weblink plug-in into
the Acrobat5 plugins directory. 

2 - Open a PDF file (there are a bunch in the help directory). 

3 - Create a link with the link tool.  When the properties dialog
comes up, you select "World Wide Web Link" from the drop down menu.
Select the "Edit URL" button to type in a URL.  Say OK to get out
of all than and then save your PDF file.   

Here is the snippet from the DDESpy log:

Task:0x76c Time:27821685 hwndTo=0x260646 Message(Sent)=Initiate:
	hwndFrom=0x120634, App=0xc057("Netscape6")
	Topic=0xc037("WWW_OpenURL")
Task:0x76c Time:27822045 hwndTo=0x280534 Message(Sent)=Initiate:
	hwndFrom=0x120634, App=0xc057("Netscape6")
	Topic=0xc037("WWW_OpenURL")
Task:0x76c Time:27822356 hwndTo=0x1100be Message(Sent)=Initiate:
	hwndFrom=0x120634, App=0xc057("Netscape6")
	Topic=0xc037("WWW_OpenURL")
Task:0x6c8 Time:27822877 hwndTo=0x120634 Message(Sent)=Ack:
	hwndFrom=0x2505e2, App=0xc057("Netscape6")status=c057(fAck fBusy )
	Topic=Item=0xc037("WWW_OpenURL")
Task:0x76c Time:27823087 hwndTo=0x2505e2 Message(Posted)=Request:
	hwndFrom=0x120634, fmt=0x1("CF_TEXT")
	Item=0xc057(""http://www.adobe.com",""...")
Task:0x6c8 Time:27823277 hwndTo=0x120634 Message(Posted)=Ack:
	hwndFrom=0x2505e2, App=* or status=0()
	Topic=Item=0xc057(""http://www.adobe.com",""...")
Task:0x76c Time:27823437 Error: #4009 = Notprocessed


Note that my modified weblink is sending the DDE messages 
in exactly the same format that it sends them to Netscape 4.X
and to IE.

Comment 28

[Peter Lubczynski]

Liz,

Thanks for the imformation on how to repo your bug. I will take a look and see 
if this is a plugin issue and if so open a SEPERATE bug but from the DDE log you 
attached it looks like Netscape reports back "busy" which I think is bug 53952 
that you may want to cc: youself on. The good news is that there are patches in 
THAT bug and it's high priority to get fixed.

Oh, one more thing, what's your user agent string from about:plugins. When 
reporting bugs, please always include this. Thanks!

Comment 29

[Arun Ranganathan]

The snippet of code that I looked at(in lxr -- the link "timeless" added in) led
me to believe that the app. name is "Mozilla" and not perhaps "Netscape6" when
it comes to looking for the DDE Server.  Am I wrong about this?

Comment 30

[av (gone)]

Looks like you are right, and the service name is not hardcoded as it might seem 
from the code but rather loaded from resources. And it is 'Mozilla' and it still 
doesn't work. I have also tried netscape6, netscp6 -- neither is working.

Another thing, looking at the code I noticed that the transaction type expected 
is XTYP_EXECUTE. NS4.x will not respond to this type, it expects XTYP_REQUEST. 
Liz, please correct me if I am wrong.

Comment 31

[timeless]

yeah execute vs. request was the change they made to break this. :)
it's mentioned in some other bug :)

Comment 32

[Viswanath Ramachandran]

nav pretriage: Bill is not going to get to this for mozilla0.9.1. Adding nsbeta1 
keyword and moving to mozilla0.9.2 at least. 

Comment 33

[lmcquarr]

FYI -- the above experiment I did was with Netscape 6 --
that is why my DDE Spy log says "Netscape6".  
I will do the same experiment this morning with the
latest mozilla milestone build. 

(FYI: Netscape 6 registers itself in the registry as "mozilla" 
under the 
key 
HKEY_LOCAL_MACHINE\software\\classes\\http\\shell\\open\\ddeexec\\application,
but the server name is Netscape6.  This is probably a Netscape 6 bug.)

Comment 34

[lmcquarr]

Peter:

I don't think that the problem I am seeing with Mozilla 
not responding to Acrobat WWW_OpenURL has
anything to do with 53952.  53952 is a DDE problem on
Win 98 and I did my exeriments on Win2K (Adobe usually
provides its engineering staff the latest computer equipment :-).

I *am* going to make a comment in 53952 about bugs we
saw with DDE and Win 98 during Acrobat 5. 

Comment 35

[Viswanath Ramachandran]

nav triage: yes we shd interop with third party apps esp adobe properly. we'll 
try to get to the bottom of this in m0.9.2. not sure if we can support all the 
topics, but www_openURL shd work correctly. 

Comment 36

[Bill Law]

Discussion thus far has led to the conclusion that:

1. We need to add code to handle XTYP_REQUEST (for topic WWW_OpenURL).
2. To implement that fully requires that we hook into existing browser windows 
and load the URLs in them).  That is problematic; there may be examples of code 
that does likewise in the Mac AppleScript code (see 
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/appleevents/nsWindowUtils
.cpp).
3. We also appear to need to pass back a "window id" that can later be used by 
the client to refer back to the window.  We don't have any obvious mechanism 
for doing that in Mozilla and need to conjure up something.

This looks like at least a couple of days work.  It requires some measure of 
Windows DDE expertise.

Comment 37

[Viswanath Ramachandran]

based on discussion with arun ranganathan: this is a beta stopping bug. if we
dont have this in, we wont interoperate correctly with adobe acrobat plugin.
hence mocing to mozilla0.9.1. 

Comment 38

[Arun Ranganathan]

law, peterl:
the dde server name for both commercial as well as mozilla browsers ought to be
"Mozilla" so that clients that embed Mozilla and our commercial browser
(Netscape 6) work for Acrobat without obliging Adobe to do lots of client
specific tweaks.  Does this make sense or pose huge probs.?

Comment 39

[Peter Lubczynski]

And if that's the case, then Acrobat won't work anyway until they "refresh" 
their plugin to look for "Mozilla" vs. "Netscape", right Liz? But I guess our 
stuff needs to be in before they will make any changes.

Comment 40

[Arun Ranganathan]

right.  the advantage of "Mozilla" is, of course, that it's not "Netscape"
specific, and also, we're not calling the Mozilla browsers Netscape (which can
-- and rightly so -- upset folks :-) ).  law, thanks for helping out on this.

Comment 41

[Bill Law]

We should think about that one.  It used to be more complicated because we were
a DDE client ourselves.  At that time, using the same application name meant you
couldn't run both Mozilla and Netscape6 at the same time.

That's not as much a problem, now though, since we are no longer a DDE client.
But, we use the same string (DDE application name) for the IPC mechanism we now
use so that code would have to change.  But that's not hard.

If I change (in my build) the application name to "Netscape", will Acrobat (a
standard reader installation) talk to us?  That would be useful for testing...

Comment 42

[Peter Lubczynski]

Liz and I spoke about that idea and I think we came up with a few "other" issues 
that come up if we emulate 4.x (like registry keys) w.r.t DDE. Liz, do you 
recall what were those problems in just completely pretending to be "Netscape" 
4.x in the DDE sense istead of "Mozilla" thereby not requiring you to make any 
changes in the PDF plugin?

Comment 43

[selmer (gone)]

Is the plan close enough that we can get a patch and iterate to completion? 
What can we do to drive this to closure more quickly?

Comment 44

[Richard Hughes]

If you're looking for uses of DDE, there's www_listwindows and www_getwindowinfo 
around too. I use them in Miranda ICQ (miranda-icq.sf.net) to get the currently 
open URLs to put in the send URL dialog, and since Mirabilis have the same 
feature I suspect they do the same.

It's not required, and definitely not 0.9.1, but it is used.

If there's another way to do it then I have no problem with implementing it, but 
I don't know of it.

Comment 45

[Phil Peterson]

Has this bug boiled down to just changing the DDE server name? If the deal is
that 4.x was "mozilla", and mozilla is "mozilla", we should be "mozilla" too.
The point of this is DDE interoperability, not branding.

If this bug means more than changing the DDE server name, I'd wait for 0.9.2,
where we may need other DDE work for embedding purposes.

Comment 46

[Peter Lubczynski]

IMO, fixing this bug requires more than just simply changing the DDE server 
name.

Comment 47

[lmcquarr]

Hi folks:

You do not need to worry about changing the DDE server name.  I have
gotten approval to make a fix to the service pack for Acrobat 5.0
to use whatever name you pick.   I  also need to do some other work
to make the acrobat functionality work with mozilla, since
the code is currently hard coded for "Netscape" or "IE".  I will
be doing all of this work for the service pack.  Just make up
your mind soon since I must type in this code in the next week or so. 

What we need fixed is for WWW_OpenURL to work as it does in 4.X
and IE.  Peter has been able to duplicate the exact problem I see
given an hacked version of the Acrobat weblink plug-in that I gave
him (this is what I will be fixing for the service pack) .  

This is what Peter said:

"So anyway, the problem is that Adobe hands us back this string for WWW_OpenURL: 
DDE: uType  =XTYP_REQUEST 
     uFmt   =1 
     hconv  =04000500 
     hsz1   =0000c001:[WWW_OpenURL] 
     hsz2   =0000c002:[","","","",""] 
     hdata  =00000000 
     dwData1=00000000 
     dwData2=00000000 

The first problem was that we weren't doing anything for XTYP_REQUEST type 
requests. The second problem is that we don't have any code in place to 
translate hsz2 into something usable. "

Comment 48

[Bill Law]

Yes, this definitely involves more than changing the DDE application name.

I've got it mostly working today.  I had to add support for topic WWW_Activate
(both XTYP_CONNECT and XTYP_REQUEST) and support for WWW_OpenURL (XTYP_REQUEST).

Remaining problems:

1. I can't quite get WWW_Activate to work (attempts to activate/focus the window
don't seem to "take").
2. I can't figure out how to load the argument URL (for WWW_OpenURL) in an
already-open Navigator window (it craps out with some security manager snafu).
3. I haven't implemented the more esoteric topics listed in the status
whiteboard yet (but they should be relatively easy).
4. It doesn't work if Mozilla isn't already running (although I didn't actually
try that).  I just don't know yet who triggers mozilla.exe to start up in that
case, or how they do it.

Liz, do you know what happens when Netscape/Mozilla isn't running?  Does Acrobat
detect the DdeConnect failure and start the browser itself?  How do you
determine how to start the browser, if that's the case?  Thanks.

BTW, I modified my build to set the DDE application name to NETSCAPE and it
seems to work just fine.

I'm hoping these remaining issues can be resolved tomorrow.

Comment 49

[selmer (gone)]

Adding mstoltz to look at the "security manager snafu".

Comment 50

[Peter Lubczynski]

Here are the instructions Liz sent me on hacking the registry for "Mozilla":

Peter:

Set mozilla up to be the default browser.

Make sure that this is the case by checking the following key:

HKEY_LOCAL_MACHINE\software\\classes\\http\\shell\\open\\ddeexec\\application

it should save "Mozilla".

Next, set up an app path for mozilla:

Go to HKEY_LOCAL_MACHINE\\software\\microsoft\\windows\\currentversion\\app 
paths

Create a new key called "mozilla.exe" and set its default value to be the path
to the mozilla executeable.


Then, Drop the attached plug-in into your acrobat plug-ins directory and 
run acrobat.


Make sure no other browser are running.

In Mozilla, browser to any PDF file and then press the Adobe button on the 
browser
toolbar (does a weblink to www.adobe.com).

Comment 51

[Viswanath Ramachandran]

adding Samir as we need his help for the branch build and the registry key 
stuff. 

Comment 52

[Bill Law]

Attachment: Patch with much improved DDE implementation

Comment 53

[Bill Law]

Patch has the bulk of the code needed to get the requested DDE topics 
implemented.

Open issues:
1. ParseDDEArg needs to handle commas within quoted strings (15 minutes)
2. If the "active Nav window" has encountered "unknown content" (i.e., shown 
the unknown content dialog), then when we try to go to the url specified on a 
WWW_OpenURL request, we get an assertion/failure in 
nsScriptSecurityManager.cpp, line 1168.  Weird.
3. WWW_Activate doesn't really work because the SetFocus() call it issues 
doesn't actually focus the most-recently used Navigator window.
4. WWW_CancelProgress, WWW_RegisterViewer, and WWW_UnRegisterViewer are just 
stubbed out so it appears they work.  They don't actually do anything.  I don't 
know how much that matters.  WWW_RegisterViewer is real hard, I think.

Comment 54

[Syd Logan]

I guess all I have are nits, in decreasing severity:

Placing topipCount in the enum assumes the compiler assigns the enum values in a
certain way, that should be hidden at this level and not relied upon.

Better thing would be to use sizeof() on topicNames:

topicCount = sizeof( topicNames ) / sizeof( char *);

This is a more accepted pattern.

Logically, topicCount is not an enum in the sense of the other values, and being
defined as such is confusing. In other words, a programmer might come in and add
an enum *after* topicCount, not realizing topicCount is what it is, and this
would introduce a logic error.

-        if ( mTopic ) {
-            DdeFreeStringHandle( mInstance, mTopic );
-            mTopic = 0;
+        for ( int i = 0; i < topicCount; i++ ) {
+            DdeFreeStringHandle( mInstance, mTopics[i] );
+            mTopics[i] = 0;

In the old code, you checked for NULL second argument to DdeFreeStringHandle().
Should you also do so in the new code? E.g.,

for ( int i ...
     if ( mTopics[i] ) 
          DdeFreeStringHandle( ...

+        do {
+            if ( !med ) {
+                break;
+            }

At first I was going to nitpic and say that med is loop invariant -- can the
check happen outside the do while loop? 

However, the while loop really isn't a while loop, just a less ugly way to avoid
nested ifs and gotos. Code doesn't read all that easy on first glance as a result. 

Nothing holding me back from r=, so I'll give it. r=syd

Comment 55

[Scott MacGregor]

sr=mscott

Comment 56

[Daniel Bratell]

Do you file bugs on the open issues after checking this in?

Comment 57

[Bill Law]

Attachment: Improved patch that incorporates Syd's comments, fixes WWW_Activate and works with "turbo mode"

Comment 58

[Bill Law]

I fixed the problem with WWW_Activate by doing a ::SetForegroundWindow whenever 
possible (plus, I added a ::ShowWindow( ..., SW_RESTORE ) for good measure to 
conform to the WWW_Activate spec).

Syd and I also worked out how to make this work properly with "turbo mode."  
The prior patch didn't account for that and if you were in turbo-mode and had 
no open Nav windows, the WWW_OpenURL wouldn't work.

Now, it properly directs the "cached" Nav window to the appropriate page.  This 
has the nice side-effect of fixing a turbo-mode bug related to bug 81712 
whereby the cached window previously always opened to about:blank.  Now, it 
should open to the proper page (home page or otherwise).

Comment 59

[Bill Law]

Yes, we will open bugs for the stuff that doesn't work right.  The two I know 
about are:

1. WWW_OpenURL requests for URLs with embedded commas.
2. Second window opens after bringing up helper app dialog.

Comment 60

[Brendan Eich [:brendan]]

syd has a point if failure to allocate a DDE String (Handle) does not preclude
the Quit method from being called; or if DDEFreeStringHandle is not null-safe. 
Not a big deal, worth fixing before checking in?

a=[e-mail] for checkin to branch and trunk.

/be

Comment 61

[Bill Law]

Thanks, Brendan.  I incorporated Syd's suggestion to only DdeFreeStringHandle 
valid mTopics.

I opened bug 84276 to address the strange security manager assertion that 
occurs after showing the helper app dialog.

I opened bug 84277 to address the potential problem handling WWW_OpenURL 
requests for URLs with embedded commas.

Any other residual problems that emerge during testing by our friends at Adobe 
should generate new bug reports.

Resolving this one FIXED.

Comment 62

[lmcquarr]

Let me clarify:  Bill believes that WWW_OpenURL and WWW_Activate should
now work?  And this is checked in so that the fresh pull I am getting
should include this work?  If so, thank you and I will be begin testing
as soon as my pull and build is done.

Comment 63

[lmcquarr]

WWW_OpenURL works!  It is beautiful!  Mr Law ... you are a god!
Thank you, all.

Comment 64

[lmcquarr]

I can see that there have been a number of mods to nsNativeAppSupportWin.cpp
since June 6 (when Bill worked on the Acrobat weblink problem) ... and I suspect
that one of these mods must have reintroduced the problem opening the document
in a new window.  

Comment 65

[Tim Adam]

We have a helper app that uses WWW_QueryURLFile with Netscape 4. When the user selects a link to a file in the browser, the file is saved to a temporary file and our app is launched with the temporary file as argv[1]. We need to map that temporary filename back to the original URL so that we can retrieve further files referenced as relative URLs in that file. Are there any plans to support this? If not, what other mechanism do you recommend? Thanks.