133751 - Mozilla Broken with Acrobat Forms in a Frame

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[lmcquarr]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
BuildID:    2002032603

Acrobat is registered as a helper application for FDF (Forms data format)and 
XFDF and RDF (assocaited with Ebooks).

When FDF comes down, it should be handed off to Acrobat as a helper app, not 
through the plug-in interface (so this is not a plug-in problem).  Most of the 
forms test cases on acroeng.adobe.com/BrowserTestSuite/forms work. The problem, 
therefore, is not with all FDF.   Just this one.  When you run the
test case, a console window flashes, FDF is posted to the server,
which returns FDF to the client, but it is never handed off to
Acrobat.


This used to work.  Somewhere it got broken.  This functionality is critical 
for Acrobat Forms support!   Most Acrobat forms are now broken.   

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:  Nothing happens.  Using Windump, I can see that the browser 
posts
the FDF data, and FDF is returned back from the server, but it never
makes it to Acrobat as a helper app, and Acrobat therefore, does
not populate the grey window (as in the expected result)



Expected Results:  A PDF file opens in the browser window (preferrably in the
same frame ... that is bug 115138)

Comment 1

[Peter Lubczynski]

Attachment: screenshot of DOS window

What I'm seeing is a helper app dialog ask me about opening the file with
Acrobat but displaying the icon of Perl. When I click to open, it appears that
nothing has happened. Slowing down my build a bit, I was able to obtain this
screenshot of what looks like Perl.exe trying to run what Acrobat should have
gotten. I wonder what happens on a system without Perl?

Comment 2

[Dave Itter]

I'm not sure if this bug is the same as the problem that I'm having, but it's close.

I created a php script to generate the fdf, and hand that back to the browser
linking to the pdf document. 

This works fine in Mozilla, when I tell php to set the /F to the filename only.
However, under windows and IE, acrobat says it can't find the file, and if I
want to browse for it. 

If I use the full URL for the /F, IE works fine (acrobat loads the pdf with the
fields filled out), but Mozilla no longer fills out the form fields.

The line that sets the /F in php is below.

Works for IE:
fdf_set_file($outfdf, "http://hostname.com/DynamicWO.pdf");
Works for Mozilla:
fdf_set_file($outfdf, "DynamicWO.pdf");  

I can put copies of the php scripts online, if that would be any help.

Comment 3

[lmcquarr]

This problem still happens in the RC and it does not seem to be related
to frames (I can make the problem happen without frames in this way):

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" TO OPEN
IN A NEW WINDOW.   This
will bring up a PDF file in in a new window.
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.

Unfortunately, this test case represents quite a number of Acrobat
forms applications that are now broken!  This used to work.
HELP!

Comment 4

[Peter Lubczynski]

Nominating...but I'm not sure if we are the right owners of this bug

Comment 5

[Peter Lubczynski]

I'm not sure where to look for the cause of this bug. I fear it may also be a
security concern as from my screenshot it looks like it runs perl.exe on some
POST data without even a warning!

Comment 6

[Peter Lubczynski]

Attachment: nsHTTP:5 log

Comment 7

[Peter Lubczynski]

Here's what I've found so far:

* Here's the stack that runs perl.exe:

nsOSHelperAppService::LaunchAppWithTempFile(nsO
nsExternalAppHandler::OpenWithApplication(nsIFile *
nsExternalAppHandler::ExecuteDesiredAction() line 13
nsExternalAppHandler::OnStopRequest(nsExternalApp
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpe
nsStreamListenerTee::OnStopRequest(nsStreamListener
nsHttpChannel::OnStopRequest(nsHttpChannel * const 
nsOnStopRequestEvent::HandleEvent() line 213

* We are passing "C:\DOCUME~1\PETERL~1\LOCALS~1\TEMP\pingFromHtml-2.pl" as the
path to |::ShellExecute| here:

aMIMEInfo->GetPreferredApplicationHandler(getter_AddRefs(application));
if (application && action == nsIMIMEInfo::useHelperApp)
{
  // if we were given an application to use then use it....otherwise
  // make the registry call to launch the app
  const char * strPath = (const char *) path;
  nsCOMPtr<nsIProcess> process = do_CreateInstance(NS_PROCESS_CONTRACTID)
  nsresult rv;
  if (NS_FAILED(rv = process->Init(application)))
    return rv;
  PRUint32 pid;
  if (NS_FAILED(rv = process->Run(PR_FALSE, &strPath, 1, &pid)))
    return rv;
}    
else // use the system default
{
  // use the app registry name to launch a shell execute....
  LONG r = (LONG) ::ShellExecute( NULL, "open", (const char *) path, NULL, NULL, 

* ...it looks like aMIMEInfo doesn't have a |GetPreferredApplicationHandler| for
the mime type 'application/vnd' although I see in the debugger
mPreferredAppDescription is |AcroExch|. Hm...I wonder why only the app
description is being set?

Comment 8

[rubydoo123]

ok, I've been doing some testing on this one, using the current trunk build 
(20020419) on win98, and using the Acrobat reader 5.0.5.20010924.

When I access the listed test case from Liz, here is what happens:
1. When I select the button, a download dialog is displayed, if I select to open 
the document, the dialog is dismissed but nothing happens.
2. If I select to download the file, open Acrobat on the desktop and then select 
to open the file. Acrobat launches mozilla and the file is then displayed in the 
mozilla window. Btw, the form works just fine in this window. This is the 
location of the file that ends up being displayed in the mozilla window:
http://acroeng.adobe.com/BrowserTestSuite/forms/pingform.pdf

Not sure if any of that info asists on this issue. My one question is though -- 
why would it launch successfully from the desktop and not straight from the 
site?

Comment 9

[lmcquarr]

THe good news is that mozilla is having the right HTTP conversation
(POST data is correct and then the server response is correct ... it is
sending back FDF).

What is broken is that despite the return mime type of application/vnd.fdf,
mozilla is launching PERL on the return data, rather than handing it off
to Acrobat, which is registered as a helper appliction for this mime type.

Comment 10

[Peter Lubczynski]

-->taking bug, although I'm not sure this is a "plugins" fix.

This could also be causing problems with other plugins as helper applications as
noted in this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=139500

Perhaps |FillContentHandlerProperties| isn't setting 
nsIMIMEInfo::mPreferredApplicationHandler, but I'll have to debug further to
find out what's going on.

Comment 11

[Boris Zbarsky [:bzbarsky]]

This  is almost certainly bug 116938.

Comment 12

[Peter Lubczynski]

Bug 116938 is already on the trunk. Can this be re-tested?

Comment 13

[rubydoo123]

Using the trunk build from2002042603 on win98, here are the results. Note I have
nscp6 set as my default browser:

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

selected 'Test going from HTML to FDF'
1. The results field remained empty
2. Now here is the odd part. The first time I selected that link, the Acrobat
application launced and the form didn't open like a windowless plug-in, rather
it opened as if it was just another frame. I closed out the nscp window but left
the acrobat app open.

3. opened a new browser window, selected 'Test going from HTML to FDF' this time
the form opened like I had expected
4. Selected first button 'Returns FDF that specifies different PDF, no #FDF in
URL. The dialog 'Downloading pingFromHtml.pl.fdf' was displayed asking to either
open or save - selected open. The acrobat window popped forward and was void of
content. The browser window showed no change.
5. Selected the second button 'Returns FDF that specifies different PDF, has
#FDF in URL. Same result as the first button
6. Selected button three 'Returns FDF that specifies no PDF, no #FDF in URL',
this time I got an alert box in acrobat:
Unable to locate the form because the FDF lacks an /F key. If the FDF came back
as a result of a submit from a PDF form, then the URL is probably missing "#FDF"
at the end.
7. Selected the last button 'Returns FDF that specifies no PDF, has #FDF in
URL.' That button had no response whatsoever.

Selected Test going from PDF to FDF
1. Result field contained: CONTENT_LENGTH is zero!
2. The buttons all reacted as in the previous test

Selected Test going from PDF to HTML
1. Selected first button -- I believe we passd on that one, a new page was
displayed with the Apache image, and so did the second button

Liz -- what exactly should we be seeing? Should the URL bar be the only thing
that updates?

Comment 14

[lmcquarr]

Can you tell me how to get the trunk build to test?

Comment 15

[rubydoo123]

nightly builds are the same thing, just grab the nightly from http://www.mozilla.org

Comment 16

[lmcquarr]

Got this build ... is this correct?
http://ftp.mozilla.org/pub/mozilla/nightly/2002-04-26-08-trunk/

I am investigating with the above trunk build. Some things are
fixed.  Some are still broken. Stay tuned ...

Comment 17

[lmcquarr]

Well the good news is that the trunk is now back at functional parity with
what was shipped in Netscape 6.X.  And basic Acrobat forms functionality is
working again.  So as far as I am concerned, this bug is fixed.

On the other hand, if you compare how mozilla works on these test cases
with how Netscape 4.X works, you can see that there are still some problems
with some of them (usually those where there is #FDF in the submit URL).
I am still investigating that problem and will enter a new bug once I have
some idea what is going on.  When I have that bug number I will put it in
this bug.

Thank you! 

Comment 18

[lmcquarr]

I meant to say "functional parity with Netscape 6.2".

Comment 19

[lmcquarr]

Hi folks:

I have entered a new bug that explains why even though this particular
bug is fixed, not all of the functionality on the above page
actually works.  That bug number is 140422.  

Comment 20

[rubydoo123]

Liz: does that mean we can now mark this one fixed?

Comment 21

[lmcquarr]

Yes -- this is fixed. 140422 is a new, but important, bug.

Comment 22

[rubydoo123]

f

Comment 23

[rubydoo123]

marking verified per Liz's comments