115138 - Open Document in SAME Frame of Same Window

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[lmcquarr]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+)
Gecko/20011213
BuildID:    2001121303

Bill Law just fixed bug 92156 -- Thank you!

This bug has to do with the implementation of WWW_OpenURL 
(the crufty old spyglass interface) opening the URL
requested in the existing window, rather than in a new window. 

Now that the bug is fixed, I see one more problem. 
Acrobat engineers worked out this deal with Netscape engineers
(back in the Internet Dark Ages ... circa 1995 and 1996) 
where not only would the document open in the exising
window, but it would open in the Active Frame!  

With Bill's fix, if there was a frameset, it goes away. 
(It at least opens in the same window .. Thank you!)



Reproducible: Always
Steps to Reproduce:
1. Install the Acrobat 5.05 Reader now available from www.adobe.com. 
2. Goto http://acroeng.adobe.com/BrowserTestSuite/forms/testforms.html
3. In the left hand frame, select "Test Going From HTML to FDF".  This
will bring up a PDF file in the right hand frame. 
3.  In the PDF file, there are three test cases.  For test case 1,
there is a button that says "Returns FDF That Specifies a PDF".  
Click that button.


Actual Results:  A PDF file opens in the entire window of same browser window,
with the text
     "CONTENT_LENGTH is zero!" in the large text edit box. 

(The frameset goes away). 

Expected Results:  A PDF file opens in the ***same frame**  of the same browser
window, with the text
     "CONTENT_LENGTH is zero!" in the large text edit box. 

(Try this with Netscape 4.X ... and you will see the behavior desired). 

Why is this important?  Many Acrobat forms applications
are built using Frames and now they are not going to work
correctly.  (NOTE: You will see that the test case says that this
does not work in IE.  Actually, for Acrobat 5, we have
added functionality that does allow it to work in IE. )

In other words, while this is not critical functionality, it
is important enough for us to spent a month fixing the IE problem
for Acrobat 5.0.

Comment 1

[Bill Law]

Not going to get to this till post 1.0.

Comment 2

[Sergey Lunegov]

Couldn't reprioduce this bug because:
when I clicked the specified button I got the fllowing error --
While trying to process the request:

POST /cgi-bin/browser/pingFromHtml.pl HTTP/1.1
Host: acroeng.adobe.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020305
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://acroeng.adobe.com/BrowserTestSuite/forms/html_to_fdf.html
Content-Type: application/x-www-form-urlencoded


The following error was encountered:

* Invalid Request

Some aspect of the HTTP Request is invalid. Possible problems:

    * Missing or unknown request method
    * Missing URL
    * Missing HTTP Identifier (HTTP/1.0)
    * Request is too large
    * Content-Length missing for POST or PUT requests
* Illegal character in hostname; underscores are not allowed 

I think this is of our proxy (or other) server misconfiguration. 
Reporter, would you please provide more simple testcase.

Comment 3

[lmcquarr]

If you try the test case in another browser (you pick :-), you will see that
it works just fine.   Either there is something wrong (as you say)
with your proxy, or the build you are using has a problem with form posting.

Sorry, but I do not have a simpler test case than that! 

Comment 4

[lmcquarr]

This is one of the highest priority bugs for me to get fixed.  The frustrating
thing is that Bill Law actually already fixed this once last June and then
it reappeared.  

Comment 5

[Peter Lubczynski]

nominating nsbeta1

Comment 6

[Peter Trudelle]

nsbeta1- per Nav triage team, ->1.2.  Sorry, we don't see a compelling need to
fix this in next release.

Comment 7

[Arun Ranganathan]

Note that we're looking at a regression here.  This was fixed at one point, and
is now broken.  Adobe PDF have certified N6.x as a supported platform, and so
this DDE  thing is key to them (see Comment 4).  Renominating it is a good idea.

Comment 8

[lmcquarr]

Arun -- you took the words right out of my mouth.  Bill Law fixed this
last June ... and he and I spent quite a while working on this before
it was fixed.  Then suddenly, it was broken again!   Sigh.

Comment 9

[Bill Law]

Liz, I remember fixing the problem with opening a new window, but that is still
fixed, I believe.  The issue here is with respect to framesets.  The code
currently loads the url specified in the incoming DDE request into the topmost
frame (replacing the frameset).  

That code has always worked that way, I believe.

I don't know whether it is possible to figure out the active frame at the point
where we're doing the load.  If there's a conventionent GetActiveFrame method in
the right interface, then this could be fixed easily.  But my suspicion is it
might not be that easy.  I recall long-lived problems elsewhere dealing with the
active frame (e.g., making "find in page" search the active frame).

Comment 10

[lmcquarr]

Hi Bill:

First off, try this test with Netscape 6.2.  The current build of mozilla
is completely broken with respect this test!  It flashes some sort of 
DOS console window that disappears.  Underneath the covers, I can
see that the FDF gets posted and then more FDF is downloaded from
the server, but it never makes it to Acrobat as a helper app. I logged
a new bug: bug #133751 . 

If you do this test with NS 6.1, you will see that a ***new*** browser window 
is opened.
This behavior is completely wrong and exactly what it was before
this bug was fixed way back in June: bug 92156

Perhaps that bug should be reopened! (Can you do this) That must be fixed! 

Finally, eventually, the sought out behavior is that there
be some mechanism that we can open a PDF file is a specific
frame  (that is what this bug is about).  The behavoir
happens by default in Netscape 4.X.  With Win IE, we have
a programmatic way to specify opening the doc in a target frame
using some interfaces associated with the browser.  

For gecko clients, if the behavior can not happen by default
(as in 4.X), then we need a way to do it programmatically.
The best way to achieve this would be to fully support
the WWW_OpenURL spec which does allow a target frame to be
specified.  I will dig up the spec and post in in my next comments.

This is long winded so let me summarize:

1 - First off, mozilla is completely broken for this test.  See 
new bug 133751.

2 - It appears that the bug that was exactly fixed in June is
back and should be reopened: 92156.  This is the critical 
bug that must be fixed for Acrobat forms to be useful.

3 - The continued path of this bug is to find some way
to get the desired functionality of having PDF open
in either the same frame, or in a target frame. 
The easiest path for me to do this is if you
folks implement the relevent part of the WWW_OpenURL spec,
which I shall paste in in my next comment. 

Comment 11

[lmcquarr]

Here is the WWW_OpenURL spec
http://developer.netscape.com/docs/manuals/communicator/DDE/ddevb.htm#www_openur
l

WWW_OpenURL: Client form
Netscape is: Client.


Transaction Type: XTYP_REQUEST.


Item (Arguments): qcsURL,[qcsSaveAs],dwWindowID,dwFlags,[qcsPostFormData],
[qcsPostMIMEType],[csProgressServer] 
qcsURL is the URL that Netscape is requesting a DDE server to handle. 
qcsSaveAs is a file that Netscape is requesting the DDE server to save the URL 
output in. 
dwWindowID is the Netscape browser window or frame cell requesting the DDE 
server to load the URL. 
dwFlags is not currently defined, and is currently always set to 0x0 for future 
compliance. 
qcsPostFormData is the form data that should be posted with the URL. 
qcsPostMIMEType is the MIME type of the form data. If not specified, and 
qcsPostFormData is specified, assume that the MIME type is application/x-www-
form-urlencoded. 
csProgressServer is a server which the receiver of this topic should send 
progress topics. This is currently not specified by Netscape. 


Data (Returns): dwServicingWindowID 
dwServicingWindowID is an arbitrary window identifier chosen by the receiver of 
this topic, indicating a successful load of qcsURL. A value of 0x0 indicates to 
Netscape that the operation failed. A value of 0xFFFFFFFF indicates that that 
URL data was not accepted by receiver of this topic, equivalent to failure. 


What I would need to have implemented to be able to specify
a target frame  is the windowID parameter.

I would also need a way to translate from a frame name to a window
ID.  To do this, I would need these other DDE apis implemented:

WWW_GetWindowInfo  -- To get window ID of active Window and then frame
names of other window IDs
WWW_ListFrameChildren -- to window ID's of the child frames
--OR --
WWW_ListWindows -- to get all of the windows 

Comment 12

[lmcquarr]

I have discovered that in some cases, this is working correctly and in some
cases, it is not:

Cases that work:

1 - Go to the above URL
2 - From the left frame, select the case "from PDF to FDF"
3 - When the PDF page appears in the right frame, select the test that
says "With #FDF in the URL"

Cases that do not work:

1 - Go to the above URL
2 - From the left frame, select the case "from PDF to FDF"
3 - When the PDF page appears in the right frame, select the test
that says "no #FDF in the URL"

Also, all of the test cases in the "HTML to FDF" cases do not
work correctly.

Comment 13

[Peter Trudelle]

removing minus for re-triage.

Comment 14

[lmcquarr]

The unfortunately truth is that there is this legacy behavior that we all have
to emulate to some extent:  Navigator 4.X.    In this bug, I am asking that
the behavior of Nav be emulated.  If you try any of these test cases with Nav 
4.X, and compare the behavior to mozilla, you will see what I mean.

Note that the test cases represent REAL customer applications associated with 
Acrobat
forms implemented in Fortune 1000 companies.

Comment 15

[Samir Gehani]

Nav triage team: nsbeta1+, adt2 rtm

Comment 16

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 17

[Judson Valeski]

bill's not working on this anymore.

Comment 18

[Judson Valeski]

these test cases bring up IE when I try to run them. I'm not able to repro the
problem described.

Comment 19

[Samir Gehani]

adt: nsbeta1-

Comment 20

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 21

[Josh Aas]

This probably isn't an issue any more and the report is quite old with a broken URL and referencing a very old version of Reader.