User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120324 Firefox/14.0a1 Build ID: 20120324031100 Steps to reproduce: Load that fillable PDF http://www.impots.gouv.fr/portal/deploiement/p1/fichedescriptiveformulaire_4244/fichedescriptiveformulaire_4244.pdf and try to fill it Actual results: Can't fill it Expected results: PDF Viewer doesn't seem to allow to fill fillable PDF forms
Dao - is this a regression as much as a v2 feature request? Perhaps we should instead be tracking another bug that prevents the add-on from being installed if the user already has a Firefox-compatible PDF viewer on their system? That would prevent "regressions" like this when pdf.js is used instead of Adobe's solution.
(In reply to Alex Keybl [:akeybl] from comment #1) > Dao - is this a regression as much as a v2 feature request? I think PDF forms are common enough that a serious reader shouldn't ship without support for them. > Perhaps we > should instead be tracking another bug that prevents the add-on from being > installed if the user already has a Firefox-compatible PDF viewer on their > system? This would somewhat undermine the whole endeavor, as most of our users would remain vulnerable to Adobe Reader security holes. Also, for fresh users, the experience of using the built-in reader, encountering a form and having to figure out that you need another reader is kind of crappy.
(In reply to Dão Gottwald [:dao] from comment #2) > (In reply to Alex Keybl [:akeybl] from comment #1) > > Dao - is this a regression as much as a v2 feature request? > > I think PDF forms are common enough that a serious reader shouldn't ship > without support for them. Understood - if that's the case, I'll track for FF14 and we should consider backing out pdf.js after the uplift to Aurora if we don't get a fix completed prior. If there's major missing functionality, this feature should probably wait till FF15.
The main problem with forms is not so much filling them out (we already have a working prototype, see https://github.com/mozilla/pdf.js/tree/master/examples/acroforms), as much as what to do after the form is filled out (print vs. save PDF). Our current printing capabilities are limited - for example, because of resource issues with long documents, we only print the pages that have been displayed already, so if someone fills out a form in the beginning of a document they might miss subsequent pages in the printout. Fixing printing will likely require a new Web API (one of our contractors is looking into this), so I don't expect this to be done any time soon. Saving to file is a more realistic solution. That's the approach adopted by the document startup Crocodoc.com, for example. We can focus on supporting this if the issue remains a blocker for landing in FF.
This is still an issue on latest Aurora (15.0a2) and Nightly (16.0a1) builds: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/16.0 Firefox/16.0 Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120625 Firefox/15.0a2
Given bug 773397, tracking for FF16's release but not FF15.
Assigning to Artur for now, we're getting closer to merge day and there's been no action on this bug for a few weeks. If we're going to hit the Firefox 16 release it would be good to get someone on this.
Is there any chance to fix this for Firefox 19?
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #9) > Is there any chance to fix this for Firefox 19? That's not possible anymore. But we should request feedback from Aadib, when he wants/can work on it.
See my comment on the corresponding GitHub issue: https://github.com/mozilla/pdf.js/issues/1459#issuecomment-13422830 firstname.lastname@example.org commented: > Printing support might not be the only blocker, users might request the "save as ..." functionality? From printing point of view, currently we are keeping only number of pages (20?), there might be a case when we will not be able to print whole document / fields. We can print now (at least in Firefox). I think we should enable the form support now for the Firefox Addon at least. For saving the file: - the download attribute has landed in Firefox - as we have _only_ to append the existing PDF data, can we create a blob that holds the concatenation of the old PDF data + the new data, create a objectURL and use the URL on the download attribute? - you can start downloading a file by calling `a.click()`, where a is the `<a download=...>` tag
(In reply to Henrik Skupin (:whimboo) [away 02/09 - 02/017] from comment #10) > (In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #9) > > Is there any chance to fix this for Firefox 19? > > That's not possible anymore. But we should request feedback from Aadib, when > he wants/can work on it. AFAIK Artur is no longer working for Mozilla. Therefore resetting the assignment flag.
I too want to see the ability to Fillout forms on Firefox/SeaMonkey and be able to send them, submit them, or Print them. I would even Like to see the ability when you have a a button or link to go back to a Web page to do so. If you want to see what I need go to my Web site http://www.phillipmjones.net/ and click on Recipes. Open any of the recipes and try to click on the come button supposed to go back to Recipes.index.html Page. AS it stands now I can only do this in Chrome.
Adding native PDF support to Firefox is a noble idea that i do support... but this feature(forms) is so crucial that i really can't believe that you went live without it. I now have to come up with some way of dealing with the thousands of Firefox users coming to my website to fill-in and print out our tax forms over the next 6 weeks who are going to be confused and/or angry. I am flabbergasted that you didn't sniff out the presence of form fields in the pdf and, if found, automatically go to the Adobe plugin(if available). Does anyone know what kind of adverse affects would occur if i changed my http header for PDF files to application/vnd.fdf ?
Most common use of fill-in forms I know are US tax forms. I've been seeing this with tax forms from the IRS as well. We are in tax season here in the US. I just turned pdfjs back on to see if it could handle these and found that it cannot. Basic support should include: - Fill-in form support - Ability to save the entered form data to a PDF file - Ability to print with form data Lacking this support, the native support should pop an alert and offer to load using Adobe Reader or other registered form compliant reader. Sample: http://www.irs.gov/pub/irs-pdf/f1040.pdf If this is going to the live channel without full support, there should probably be an easy button for users to switch or a failover process. Hopefully pdfjs doesn't become a hack magnet like Adobe. Their incessant updates/patches are a bit irritating.
A Capesius, PDF Viewer is already in the release channel. When PDF Viewer detects it won't render well a PDF file, it displays an info bar with a button that opens the file with an external PDF application or downloads it.
Thanks, I see that now. Not sure what the issue was or if I just missed the info bar. I was prompted to install a beta update this morning. It is now prompting to launch the external viewer and the PDFs are now showing color as well.
Following up. The warning message is not always displayed or is deferred. In this sample PDF, the incompatibility error doesn't display until page 5 is loaded. The error is deferred until the users scrolls and the page loads. http://www.adobe.com/products/server/pdfs/adobe_barcoded_paper_forms_solution_customer_faq.pdf But, the fill-in forms I've tested have all triggered the message immediately.
A Capesius, file a new bug as comment 19 is not about the ability to fill in forms but being warned of unfillable forms.
Do I understand correctly that this has been a known bug since March 2012? Any idea when it will / or might ... be corrected? Thanks
(In reply to Alex Keybl [:akeybl] from comment #1) > Dao - is this a regression as much as a v2 feature request? Perhaps we > should instead be tracking another bug that prevents the add-on from being > installed if the user already has a Firefox-compatible PDF viewer on their > system? That would prevent "regressions" like this when pdf.js is used > instead of Adobe's solution. Problem is That the adobe plugins does not work at all on Mac. Haven't for several years now. Mozilla and Adobe seems to butt heads on this issue adobe blames Mozilla for blocking attempts to use. And I've asked fix the issue. I received back an insulting response They have no intention of fixing the issue they were not interested (I've cleaned up the langiage)
Instead of having people go to Aodobe. Make the built in solution Fill in forms
Would be great to have AcroForm support as a first step.