lmcquarr Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (Windows NT 5.0; U)
BuildID:    2001072403

I spent a lot of time in late May and early June
with various folks working on getting the DDE implementation
of WWW_OpenURL working with Acrobat.  A few parts
of this old Spyglass interface are critical to making
Acrobat forms work, and WWW_OpenURL is the king pin.

I thought we had everything fixed (See bug 25699).  
Unfortunately, while running through our complete
browser test suite this week, I discovered a remaining
problem -- one that I think reappeared since I am 
fairly sure I had a long discussion about this with Peter L.

The problem is that when we invoke WWW_OpenURL, it opens
the document in a NEW window, rather than the current window.

This is a problem because it really messes up Acrobat
forms, including a premiere application of Acrobat
forms -- Office Courier  (see http://www.movaris.com)
for more details.   Imagine filling in an electronic
form, pressing the submit button, and expecting a
form to be returned in your browser window.  Instead
what happens is that a new browser window is launched
and the form is returned there -- it is VERY confusing.




Reproducible: Always
Steps to Reproduce:
1.Go to http://access.adobe.com/browser/cookbook.pdf (or any other PDF file)
2.Select the Adobe button on the toolbar (upper right corner)
3.

Actual Results:  A new browser window opens and browses to http://www.adobe.com.

Expected Results:  The current browser window browses to www.adobe.com.



This is not a show stopper .. just very close to it.
In other words, you can ship with this, but please, please
make it a top priority for a dot release.

	lmcquarr Reporter
	Comment 1 • 23 years ago

The thing about this bug that really confuses me is that I know I had
conversations about this with Peter, and my recollections are that
it was fixed, but now I can not find the electronic trail to 
proove that.

Peter?

	Peter Lubczynski
	Comment 2 • 23 years ago

Yes, I thought this was fixed too, by Bill Law.

	Paul Chen
	Comment 3 • 23 years ago

-> law

	Bill Law Assignee
	Comment 4 • 23 years ago

Please see bug 84573.  Could this be a dup?

It seems like this one isn't talking about just *sometimes* though.

Setting target milestone for the next mozilla release.

	lmcquarr Reporter
	Comment 5 • 23 years ago

Unfortunately, this is not a duplicate of bug 84573. For testing purposes, I 
removed the few instances of WWW_Activate from our code.  I could still
repo the bug.

	Bill Law Assignee
	Comment 6 • 23 years ago

I'm having trouble with this one.

It seems like "web links" are working in general, right?  I can click on a web 
link inside an Acrobat document and the browser window goes to the page.  That 
works with both Acrobat 4.0 and 5.0.

Clicking on the Acrobat icon in the Acrobat tool bar is another matter.  With 
Acrobat 4.0, I tried various settings of the "Web links" prefs and couldn't get 
it to work.  It seemed to be invoking the application I specified in the web 
links pref setting, but didn't pass the URL.  So I was getting a blank window.

With Acrobat 5.0, there is no longer any web link pref setting (that I could 
find).  Clicking on the Acrobat icon in the plug-in toolbar opens up an IE 
window.

So now I'm confused about how this should work.  And I'm not sure how this 
relates back to the specific issue of handling Acrobat form submission.

I think we're probably not using the same DDE application name as Acrobat is 
looking for.  When I was testing our DDE support, I used to change our 
application name to "Netscape" to get Acrobat to work.  Perhaps I still need to 
do that (even with Acrobat 5.0)?

Liz, can you give me more guidance as to what Acrobat is looking for and how it 
will communicate with us.  Is it different in Acrobat 4.0 vs. 5.0?

	lmcquarr Reporter
	Comment 7 • 23 years ago

Hi Bill!  Let me start with the basics (the DDE server name that we are looking 
for):  What you need is Acrobat 5.05, which is our SP1, which is the
first Acrobat to officially support Netscape 6.1 (primarily because of this
DDE server name issue).  It just "shipped" .. .however it is not posted on
www.adobe.com yet.   Please ping
me (AIM name == LizLizMcQuarrie) when you are back working on this and I will
email (FTP or?) you a copy. 

Next -- I need to point you to an excellent test case for duplicating this
problem that I just put on our browser test suite:


METHOD to REPRODUCE

1) Go to:

http://acroeng.adobe.com/BrowserTestSuite/forms/testforms.html

2) In the left pane, click "Test Going From HTML to PDF".  This will bring
up an HTML page in the right pane.  

3) In the right pane, click the first button  "Returns FDF That Specifies a PDF"

RESULT:

PDF is opened in NEW mozilla window.

EXPECTED RESULT:

PDF is opened in the right pane of existing mozilla window.


(Note that a number of cases in this test suite will repo the
behavior).


Does this get you started?

	Bill Law Assignee
	Comment 8 • 23 years ago

Yes, that's more than enough to get me started; thanks.

I think that getting Acrobat to use the same dde application name we are will
clear up much of the confusion on my end.  Please email me the updated Acrobat
version, if that's OK.  Thanks also for the test document(s).  Your help is much
appreciated.

	Arun Ranganathan
	Comment 9 • 23 years ago

Bill,

For those inside the NSCP/AOL firewall, Liz has mailed me this latest Acrobat
installer.  Here it is:
http://elwood.mcom.com/~arun/plugins/AcRd5ENU.exe

	Peter Lubczynski
	Comment 10 • 23 years ago

Here's the DDE spec we publish:
http://developer.netscape.com/docs/manuals/communicator/DDE/index.htm

	Bill Law Assignee
	Comment 11 • 23 years ago

Have to push this out till next milestone.

	Ben Goodger (use ben at mozilla dot org for email)
	Comment 13 • 23 years ago

Comment on attachment 61330 [details] [diff] [review]
Fix to pass "newWindow" arg from HandleRequest through to OpenBrowserWindow

sr=ben@netscape.com

	Stephen P. Morse
	Comment 14 • 23 years ago

Comment on attachment 61330 [details] [diff] [review]
Fix to pass "newWindow" arg from HandleRequest through to OpenBrowserWindow

r=morse

	Bill Law Assignee
	Comment 15 • 23 years ago

fixed

	lmcquarr Reporter
	Comment 16 • 23 years ago

Awesome, Bill!  Thank you!  Can some one ping me when it is in 
the next build so I can try it out? 

	lmcquarr Reporter
	Comment 17 • 23 years ago

I downloaded the 12/13 003 build and verified that the fix works.  

Thank you, Bill!  This is great! YIPPEEE! 

BUTTTTTT .... now that this works, I have found another bug related to this 
(that is it opening not only in the same window, but in the same frame).

I will, however, enter a new bug for this and it is a much lower priority. 

	lmcquarr Reporter
	Comment 18 • 23 years ago

The new bug number is 115138 .

	sairuh (rarely reading bugmail)
	Comment 19 • 23 years ago

rs vrfy, based on comment 17.

	timeless
	Comment 20 • 21 years ago

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

	timeless
	Comment 21 • 21 years ago

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