22.79 KB, text/plain
I'm reporting this but I'm not sure how you can reproduce it. I am running the current beta. AFAIK this problem exists for all versions of the beta. I have of course run with an empty profile to reproduce this. The story is that the con edison web site allows bill viewing when logged in. I use foxit and the foxit pluging for viewing pdf. Then I try to view a bill, a new window opens, the download appears to happen, and then the message Format error: Not a pdf or corrupted appears. But !!! This does not happen with aurora. A mozregression went right past the beta without failing! Because this requires a log in, I don't know how to tell you to reproduce it. Other facts. If I switch to using foxit rather than the foxit plugin, the pdf opens correctly in foxit. The build in pdf viewer works correctly.
This is really strange. The access works correctly on 40 aurora and 40.0.3 release but fails on 40B9 It works on 41 aurora but fails on 41b7. A beta is supposed to be the same bits as the release - isn't it? And ideas?
You should contact the developer of foxit about this. It's likely they need to fix something on their side in order for the add-on to work on beta.
It would be useful to know what is different about beta from release - they are supposed to be the same!
I misreported what works above. the 40.0 release does NOT work, but the 40.0.3 release does. Because this can't be reproduced without having a con ed account, I'm hoping someone can guess what the difference might be that can be reported to foxit.
Marc, a major difference between the Aurora and Beta channels is that multi-process Firefox (e10s) is currently enabled in Aurora (and then disabled in Beta). In the future, if you are bisecting a regression that you suspect might be related to e10s or multi-process code (e.g. plugins, which run in their own sandbox process), you can create a user profile with e10s disabled and then tell mozregression to use that user profile. Looking at the Firefox release notes for 40.0.x, I suspect this bug was "fixed" by bug 1198590 (which disabled an optimization that tried to initialize NPAPI plugins asynchronously). I will make this bug block bug 1198590, which is tracking regressions from asynchronous plugin initialization. https://www.mozilla.org/en-US/firefox/40.0.3/releasenotes/
We are whitelisting async init to work on specific plugins only, so foxit won't be affected in the next release.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
I have verified that turning off async init resolves this issue.
Marc, please use latest beta 9 and check if it works with a clean profile: http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/41.0b9-candidates/build1/ Thank You!
OK - it works except. If I am in ask to activate mode and the request to activate appears and I click activate, I see the failure! If I then open the same document again it works. If I choose always activate it will continue to work after a restart. Otherwise, after each restart it will fail on the first activate and then work. Running foxit as always activate (the only sensible setting IMHO) it always works.
This is working fine for me. Petruta, can you verify this on beta9 as well? (You'll need to disable PDF.js)
Aaron, unfortunately I couldn't reproduce the initial issue. The pdf's were either downloaded or directly opened, but I never saw the error. I tried with pdf samples and pdf's opened from webpages. Marc, can you reproduce if you open PDFs from this link http://www.coned.com/es/ ? (User Guide, Gift policy, Product Recall etc. are all opening pdf's). Is there any other public pdf you encountered that reproduce this? I disabled pdf.js and set "Use Foxit Reader Plugin for Mozilla (in Firefox)" in about:preferences#applications.
Flags: needinfo?(petruta.rasa) → needinfo?(marcausl)
Marc, sorry to bother you again. Can you please check if your comment 9 is still available with Firefox 42 beta 1? https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/42.0b1-candidates/build1/ I believe that the new patch in bug 1194488 fixed this too, but please confirm if it works fine now with this build where asyncInit is set to true by default.
I'm sorry to report that the comment 9 behavior has not gone away or changed in 42B1 And please don't hesitate to ask me to help - since you are trying to fix something you can't reproduce!
Aaron, I'm reopening based on above comments, to make sure it stays on our radar.
Status: RESOLVED → REOPENED
status-firefox42: --- → affected
Ever confirmed: true
Resolution: FIXED → ---
I'm seeing what I suspect is a related issue. Running in activate always, the first time I try to open a bill, the plugin sometimes "hangs" after starting to display the pdf. I get the plugin busy popup and if I stop the plugin, trying again always seems to work. I smell some sort of race between a delay in the plugin and it's fetching the file. The first time the plugin code comes from disk, but after that it comes from the file cache. Just an uneducated guess of course. But the original failure also involves a delay, in this case the activate sequence.
I've now seen the "hang" on a normal pdf displayed in a new tab rather than a new window. The url was: http://www.dslreports.com/r0/download/2238958~d67e6d81dad769987a5744d34e588392/October%20SamKnows%20Panelist%20Report%20Card.pdf but I suspect thats not relevant. This happened at the first access after a reboot, and that may be relevant. By hang I mean I get a plugin busy pop up and letting it continue just leads to another plugin busy etc. till I kill it. I can't reproduce this.
http://www.kingston.com/datasheets/DTDUO_us.pdf pretty reliably triggers the hang I've reported above.
Win 7 64-bit, Firefox 42 beta 6: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 I have "Use Foxit Reader Plugin for Mozilla (in Firefox)" (126.96.36.1994) set in about:preferences#applications for PDF. I tried with both pdf's above but couldn't see the hangs.
Async plugin init is defunct.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 10 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.