Just sits there connecting to server. Log reveals hang on NPN_Post: NPN_PostURL: npp=2fb2ed0, target=_current, file=1, len=54, url=http://acroeng.adobe.com/cgi-bin/browser/ping-pdf.pl, buf=file:///C:\DOCUME~1\PETERL~1\LOCALS~1\Temp\PDF8F22.tmp

WFM with Acrobat 5.0

Submit as PDF posts binary data. Posting binary data used to be broken (see 77603). This was fixed at some point and made it in NS 6.2. Now it is broken again?

Peter -- http://acroeng.adobe.com/BrowserTestSuite/forms/SubmitAsPDF.pdf This works OK for me using the build that you emailed me last Friday. It doesn't seem broken. (Note that I am connecting through a proxy server. I will try a direct connection too.) ????

Tried a direct connection to the internet and this test case still worked just fine for me. The build peter sent me is 030803

nominating nsbeta1

WFM today ;) Feel free to reopen if you don't agree. nppdf32.dll 5.0.5.452

certainly wfm.(0311)

This bug needs to be opened! It no longer works in today's build (2002041903) or in the RC1! Yikes! What happened? I am pretty sure it is again related to submitting binary data. I have another test on an internal web site that submits binary data and it is also broken. BUMMER!

reopening based on Liz's comment

putting out to 1.0.1

investigating...

just tried this on today's build (20020419) on win98 and using Acrobat 5.0.5.20010924 and this does not work. However, this does not work using Opera 6 or IE6 either.

plugin's post works fine, but the strange thing is with a temp file prepared by acrobat to post, it appears already has some http headers in it, after 3 clicks on submit button temp file looks like: Content-Type: application/pdf Content-Length: 22574 Referer: http://acroeng.adobe.com/cgi-bin/browser/ping-pdf.pl Content-Type: application/pdf Content-Length: 22455 Referer: http://acroeng.adobe.com/cgi-bin/browser/ping-pdf.pl Content-Type: application/pdf Content-Length: 22325 Referer: http://acroeng.adobe.com/BrowserTestSuite/forms/SubmitAsPDF.pdf %PDF-1.4 %ту╧╙ 7 0 obj << it can probably confuse the server side script which handles such post. moreover, when mozilla plugin code doing http POST of local file it does add additional Content-Length: header with value == file len, this is how it works for any type of file since bug 115308 was fixed (checked in the trunk on 2002-01-30). Liz, I'm just wondering is there any hack in acrobat code to write Content-Length: into the file before to POST it?

One of the undocumented aspects of the NS api is that when a temp file is being submitting, it may contain headers. What the browser is supposed to do is use send HTTP headers in addition to its own, remove them from the data to post, and then post the data. Try this example with Netscape 4.X and Windump to see what data is supposed to be posted.

Serge, with the testing we did -- selecting submit results in no action, although I see the signed data within the signature box

Liz, you are right, according to the spec http://developer.netscape.com/docs/manuals/communicator/plugin/pgfn2.htm#1007707 "For protocols in which the headers must be distinguished from the body, such as HTTP, the buffer or file should contain the headers, followed by a blank line, then the body. If no custom headers are required, simply add a blank line ('\n') to the beginning of the file or buffer. " Hmm, the file part sounds strange to me, but anyway if spec says so, we have to parse post file content to find out if there are the headers, but probably for http protocol only. Beth: I'm not sure what we suppose to see on the client side, I stop in debugger and see we are doing http POST of the file acrobat asks us to post. Probably Liz can explain how we can verify on the client side the post was successfully completed w/o sniffing network activities. Taking bug.

Verifying that this is fixed is probably as easy as making sure that this test case works (compare to NS 4.X). A side note: I spend a lot of time using Windump (windows version of TCP dump) to examine the HTTP conversations between client and server, since I don't have access to breakpoints in the browser code. If you need a leg up using this tool, I have some notes I can send you.

read & parse first <= 1K bytes from posted file. Peter, could you r= on this, please.

Comment on attachment 80730 [details] [diff] [review] patch v1 r=peterl

Darin, could you take a look and sr=, please?

bumping up to ADT2

Comment on attachment 80730 [details] [diff] [review] patch v1 sr=darin

Checked in on the trunk /mozilla/modules/plugin/base/src/nsIPluginHost.h,v <-- nsIPluginHost.h new revision: 1.29; previous revision: 1.28 /mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.376; previous revision: 1.375 --- thanks all.

nominating for the branch

This is ready to go -- it's been SR'd and so forth. Can we have this for beta? Can it be ADT1?

Note: This patch fixes not only fixes this bug, but also at least two other known problems.

adding adt1.0.0-. We'll get this in for rtm.

very sad that this is not allowed into the branch -- it's working great on the trunk

Yep! Works GREAT in the trunk build. Hooray! Thanks! Yippeee! Come on, Scott P. .... what do you think? :-)

Changing impact to [adt1 RTM], so this is taken after MachV beta.

Hi Folks: If you choose to go beta without this fix, users of the beta and Acrobat will NOT be able to do these things: - Purchase electronic books (available from all major book selling web sites as PDF ... amazon, barnes and noble, etc) - Digital signatures of electronic documents (this is big on corporate intranets ... and soon to be on government web sites) - AND a whole variety of Acrobat forms solutions that require the ability to post binary data will be broken. Acrobat forms is the big thing now. Many corporations are entirely automating their forms, including routing them. Some percentage of those forms applications require the ability to post binary data. Those corp customers will find that forms that used to work now suddenly give them strange error messages. (I am not entirely sure what thing you had to fix in mozilla. I presume it was submitting binary data ... my comments above are related to the inability to submit binary data. )

Adding adt1.0.0+ for 1.0 branch checkin approval. Please get drivers approval before checking in.

WFM on Win2k w/Acrobat 5.05 and 2002051408 build.

Signed Acrobat Document using Win XP trunk build 2002051408

Comment on attachment 80730 [details] [diff] [review] patch v1 a=rjesup@wgate.com for drivers. Please check into branch

Checked in on MOZILLA_1_0_0_BRANCH mozilla/modules/plugin/base/src/nsIPluginHost.h,v <-- nsIPluginHost.h new revision: 1.27.2.4; previous revision: 1.27.2.3 nsPluginHostImpl.cpp; mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.372.2.12; previous revision: 1.372.2.11 Resolved as fixed. Thanks all.

tested this on win98 using branch bits from 20020516 and I was able to successfully sign the form and submit. Note: you must have the Adobe full install, not just Acrobat Reader. I also ran through Plug-in verification testing as well to ensure this check-in did not affect other plug-ins. http://mozilla.org/quality/smoketests/ 3(o). Browser Plugins (optional) -- all tests passed as expected http://mozilla.org/quality/browser/front-end/testcases/plugins/ -- all test passed as expected http://acroeng.adobe.com/BrowserTestSuite/ -- tests passed as expected http://jazz/users/shrir/publish/flashacceptancesuite/ -- tests passed as expected Plug-ins tested: Acrobat 5.0 QuickTime 5.02 Flash 6.0 r23 Media Player 6.4 RealPlayer8 Shockwave 8.5 WinAmp 2.80

v