Closed Bug 739043 Opened 13 years ago Closed 4 years ago

Can't fill fillable PDF forms with PDF Viewer

Categories

(Firefox :: PDF Viewer, defect)

Product:
Firefox
Component:
PDF Viewer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1673086
Tracking Flags:
Tracking Status
firefox15 - ---
firefox16 - ---

People

(Reporter: anti-stress, Unassigned)

References

Details

(Keywords: parity-chrome, parity-edge, Whiteboard: [pdfjs-c-feature])

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
Blocks: 714712
Component: Untriaged → PDF Viewer
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
tracking-firefox14: --- → ?
QA Contact: untriaged → pdf-viewer
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.
tracking-firefox14: ? → +
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.
tracking-firefox15: + → -
tracking-firefox16: --- → +
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.
Assignee: nobody → aadib
Blocks: 748923
Whiteboard: [pdfjs-c-feature]
No longer blocks: 748923
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.
Flags: needinfo?(aadib)
See my comment on the corresponding GitHub issue: https://github.com/mozilla/pdf.js/issues/1459#issuecomment-13422830 ydelendik@mozilla.com 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.
Assignee: aadib → nobody
Flags: needinfo?(aadib)
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.
See Also: → 1158610
I read through the previous comments. I generated Bug 1453068 today. I did some research and did not see this previous bug. Anyway, last year I was able to fill-in my tax forms using Firefox. This year I had to switch to Internet Explorer. Microsoft Edge and Chrome did not work. I will continue to use Internet Explorer until Firefox develops a suitable solution.
I will say with the bug I submitted the PDF form does not show at all. If you bring up the page (https://ww2.revenue.wi.gov/Internet/wi_efile/2017/Form1-2017.pdf) in Firefox you will see the error that is displayed. The message reads "This PDF document contains forms. The filling of form fields is not supported." The main body says "Please wait... If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document. You can upgrade to the latest version of Adobe Reader for Windows®, Mac, or Linux® by visiting http://www.adobe.com/products/acrobat/readstep2.html." I did try to upgrade my reader but I have the latest version. As I said previously it works fine using Internet Explorer.
It would be great if the PDF would display. Being able to fill in the form fields is a valid but separate and secondary concern. The form needs to render.
I absolutely agree! It used to display a year ago in the last tax season.
And also used to be fillable.
I am wondering whether bug 1453068 and this one are actually the same, as the issue outlined by metzgerwarren is actually that Firefox' PDF viewer doesn't support scripting/accessing external resources. Sebastian
Is this ever going to be added to Firefox? Since March 7, 2017 Version 52 the NPAPI plugins got removed, the Adobe Reader in Firefox doesn't work anymore and now Firefox is at Version 63...

https://www.canada.ca/content/dam/ircc/migration/ircc/english/passport/forms/pdf/pptc155.pdf
renders on Firefox (I'm on Nightly 68) but is not fillable. I can only fill in the form using Chrome.

I tried this year's Wisconsin tax forms in Chrome and Firefox. Doesn't render with either of those. Still only works with Internet Explorer.

The problem with the Wisconsin tax forms is a different bug/missing-feature.

This bug is only about making sure that fill-in fields work. I could not find a bug for the issue with the Wisconsin tax forms so that should probably be a new bug called something like "Can't view XFA-based PDF documents".

I tried submitting a separate bug last year but it was combined with this one.

(In reply to metzgerwarren from comment #44)

I tried submitting a separate bug last year but it was combined with this one.

For reference, that was Bug 1453068. There I wrote that the issue looks rather related to scripting support, because the document displays this message:

If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document.

Later on it was closed as a duplicate of this bug, though, because of the notification bar being displayed saying that the document contains forms. The person that closed the bug also referred to bug 1100769, which covers adding JavaScript support to the PDF Viewer.

Sebastian

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Eight years and this hasn't been implemented yet? Seeing as other browsers have had this capability for a loooong time don't you think Fx should too? I mention this with the utmost respect.

Brendan, isn't that bug fixed now with one of the latest releases?

Flags: needinfo?(bdahl)

Yeah, enabled in bug 1673086.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bdahl)
Resolution: --- → FIXED
Resolution: FIXED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.