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.
Not going to get to this till post 1.0.
Target Milestone: --- → mozilla1.0.1
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.
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!
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.
nsbeta1- per Nav triage team, ->1.2. Sorry, we don't see a compelling need to fix this in next release.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
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.
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.
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).
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.
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
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.
removing minus for re-triage.
Keywords: nsbeta1- → nsbeta1
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.
Nav triage team: nsbeta1+, adt2 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 rtm]
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
bill's not working on this anymore.
Assignee: law → nobody
Target Milestone: mozilla1.2alpha → ---
these test cases bring up IE when I try to run them. I'm not able to repro the problem described.
Keywords: topembed+ → topembed-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt2 rtm]
Filter on "Nobody_NScomTLD_20080620"
QA Contact: shrir → plugins
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.