140422 - NPN_PostURL with "#FDF" At the End of Submit URL Messes up Routing FDF Back to Acrobat as Helper App

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P2)

Description

[lmcquarr]

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

The latest build has got the fix to #133751 so that a good majority of Acrobat 
forms functionality will work again. Yeh!  Thank you!

Unfortunately, there is a still a lingering, subtle bug associated
with forms submits where the submit URL ends with a #FDF.

Now you may be wondering why we are appending #FDF to the end of the URL?  
Well, it is a long, ugly story ... but basically, to make
Acrobat forms work in all sorts of browser environements has been challenging 
(at best) and a lot of hacking (at worst).  The #FDF
is a secret flag that has been in use for at least five years, unfortunately, 
and we need to make it work in mozilla. 

What is happening in the test case I provide below is that mozilla is actually 
submitting the post data, and the response (in FDF, the forms data format) is 
coming back, but mozilla is not handing that
data off to Acrobat, which is registered as a helper application for
FDF.

Note in my test cases the it works properly if there is NO #FDF
on the Submit URL.  It is, therefore, something bizarre about the
#FDF that is causing the bug. 


Reproducible: Always
Steps to Reproduce:
1.Install Acrobat 5 Reader, and Go to the above URL. 
2.In the left pane, select "Going From PDF to FDF".  This will bring
up a PDF file in the right frame with several buttons.
3. First, select the first button "Returns FDF that specifies different PDF, no 
#FDF in URL".  This will bring up a 
different PDF file in the entire window. 
4. Select the back button to return to the first PDF. Now
select the second button ""Returns FDF that specifies different PDF, has #FDF 
in URL".

Actual Results:  Nothing happens. 

Expected Results:  Brings up second PDF file in the entire window (compare to
another browser ... like NS 4.X or IE), just like the first
case where there is no #FDF in the URL

As I mentioned in my previous discussions about various bugs
in mozilla associated with Acrobat forms, Acrobat forms is 
a huge, growing market for Acrobat.  Unfortunately, the use
of #FDF is quite common in our forms applications, because
it fixes problems associated with gluing forms functionality into
various browsers.  It is, therefore, critical that this get
fixed.

Comment 1

[rubydoo123]

assigning to Peter, putting into 1.1 alpha

Comment 2

[lmcquarr]

For what every magical reason, this is working EXCELLENTLY in today's build!
2002052304.

In other words, it no longer appears to be broken.

(I will also check the trunk build for today.)

Comment 3

[Peter Lubczynski]

marking WFM based on last comment

Comment 4

[serge (gone)]

yea, it fixed by check in for bug 139572

Comment 5

[lmcquarr]

Serge -- THANK YOU for all of your excellent work.  

This morning, I took today's build for a spin through our entire
Acrobat forms test suite, and except for a remaining problem
associated with WWW_OpenURL and DDE (in some cases, it opens the data in 
the entire window, rather than the same frame ... see bug 115138), it worked 
FLAWLESSLY!

I am thrilled!  Yippee!