User Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121010144125 Steps to reproduce: I tried to print out the shipping address of a buyer on eBay. Actual results: With plugins.click_to_play set to true, I got a blank PDF without address. Expected results: The address should have appeared after enabling the Adobe Acrobat PDF plugin.

dupe via bug 743060

I still have this issue with Adobe's Acrobat plugin. The PDF preview in Firefox (built-in PDF viewer) is not affected, I guess it's because it bypasses click-to-play, it's not handled like an ordinary plugin. I can't use the PDF preview though because for some reason the quality when printing is very low.

I have now installed the Sumatra PDF viewer to check if it's an Adobe specific issue, and Sumatra can't display the PDF either when click-to-play is enabled. However it gives as concrete error message, it says that it can't open the temporary file.

What are the exact steps to trigger this on ebay? Is it possible to construct a reduced test-case for this (i.e. one that doesn't depend on ebay)?

Is this file being generated via POST? The last time I checked, we still had an important bug about saving off POSTdata pages for CTP, because retriggering the POST would be bad.

Yes I'm pretty sure it's POST, that's why I mean by "generated". If someone could provide a different website where the PDF is created on-the-fly using POST data, this would be a reduced test case that doesn't depend on eBay. I guess there already is a bug then describing the same issue, about POST and CTP?

Exact steps for eBay: 1. Go to about:config, enable "plugins.click_to_play". 2. Have any plugin like Adobe Acrobat or Sumatra PDF installed and enabled. 3. In settings, applications ("Anwendungen" in German), search for PDF and make sure the plugin handles the PDF, e.g. "Adobe Acrobat (in Firefox)". 4. Go to the "Sold" page on eBay. 5. Click on any article that you have sold. 6. Click on prepare shipping ("Versand vorbereiten" in German). 7. Click "Only print address label". 8. Choose "print on paper". 9. Choose any options like "book transport" - I always do, so this may be a necessary step to reproduce the error. 10. Click "continue to printing". 11. A pop-up window will appear with the currently disabled PDF due to click-to-play. 12. Click to activate the plugin. 13a. Using the Adobe Acrobat plugin, you will get a blank page. 13b. If you used Sumatra PDF instead, it will give an error message that it was unable to open the temporary file. As mentioned, the whole reason why I use a plugin is because of the bad printing quality of the PDF preview. For only printing out the address this may be acceptable, however I read that bar codes for packets (Hermes and DHL here in Germany) can't be scanned when the PDF preview is used for printing these.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > Is this file being generated via POST? The last time I checked, we still had > an important bug about saving off POSTdata pages for CTP, because > retriggering the POST would be bad. This sounds like something I'd fix, but I can't find the bug :(

johns, I didn't find a bug, only the cautionary comments in bug 736998 (comments 7 & 20).

Is this website also using POST? http://www.amazon.de/Philips-HD9140-91-Dampfgarer-Aromaverst%C3%A4rker/dp/B004LVPK90 The Flash video (4th image) doesn't play if click-to-play is enabled and I don't even get the chance to enable the plugin. I just get a black image, clicking it does nothing. If I disable click-to-play, the Flash video plays just fine.

Ignore my previous comment, I've removed plugin permissions for this page but wasn't aware of it. The setting isn't displayed correctly in "about:permissions" either (it was showing "always ask"), but changing the value to something else and then back again to "always ask" works.

> This sounds like something I'd fix, but I can't find the bug :( Let's make this the bug?

Thorsten, do you still reproduce this in the latest nightly ? http://nightly.mozilla.org/ I can't find a public testcase for this.

(In reply to Paul Silaghi [QA] from comment #13) > Thorsten, do you still reproduce this in the latest nightly ? > http://nightly.mozilla.org/ > I can't find a public testcase for this. Hi, nope, still not fixed. I used the nightly firefox-25.0a1.en-US.win32.installer-stub.exe, with the firefox.exe having a version number of 25.0.0.4949, dated 20.07.2013 15:24:12, BuildID 20130720030214. Created a new profile for the nightly, and in addons, plugins, changed the defaults from "allow" to "ask". And in application settings within Firefox I changed PDF to "open Adobe Reader in Firefox". Allowed pop-ups. When I "click-to-play" I get a pop-up saying this: Adobe Reader Datei beginnt nicht mit "%PDF-". Local\EWH69lz]smv OK On regular Firefox I'm using NoScript instead of click-to-play, it resends the data and works fine then. Though I don't get why it is necessary to have the web server send the data twice. Either don't even ask the web server for data in the first place before you click, or if you send a request in advance then cache the web server's reply instead of asking for the same data again.

NPAPI plugins aren't supported any more, so I guess that this should be marked as WONTFIX.