Last Comment Bug 739043 - Can't fill fillable PDF forms with PDF Viewer
: Can't fill fillable PDF forms with PDF Viewer
Status: NEW
[pdfjs-c-feature]
:
Product: Firefox
Classification: Client Software
Component: PDF Viewer (show other bugs)
: Trunk
: All All
: -- normal with 30 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 780977 844943 853355 904997 988468 1226970 (view as bug list)
Depends on:
Blocks: 714712
  Show dependency treegraph
 
Reported: 2012-03-25 04:18 PDT by antistress
Modified: 2016-07-09 08:31 PDT (History)
42 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
-


Attachments

Description antistress 2012-03-25 04:18:19 PDT
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
Comment 1 Alex Keybl [:akeybl] 2012-03-30 10:53:22 PDT
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.
Comment 2 Dão Gottwald [:dao] 2012-03-30 11:28:12 PDT
(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.
Comment 3 Alex Keybl [:akeybl] 2012-03-30 12:55:19 PDT
(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.
Comment 4 Artur Adib 2012-04-05 08:01:34 PDT
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.
Comment 5 Mihaela Velimiroviciu (:mihaelav) 2012-06-26 07:00:37 PDT
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
Comment 6 Alex Keybl [:akeybl] 2012-07-16 08:40:16 PDT
Given bug 773397, tracking for FF16's release but not FF15.
Comment 7 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-08 09:35:31 PDT
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.
Comment 8 Yury Delendik (:yury) 2012-08-28 09:02:37 PDT
*** Bug 780977 has been marked as a duplicate of this bug. ***
Comment 9 Mihaela Velimiroviciu (:mihaelav) 2013-01-23 23:40:51 PST
Is there any chance to fix this for Firefox 19?
Comment 10 Henrik Skupin (:whimboo) 2013-01-25 06:42:24 PST
(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.
Comment 11 Julian Viereck 2013-02-12 00:46:56 PST
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
Comment 12 Julian Viereck 2013-02-12 00:57:32 PST
(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.
Comment 13 Phillip M. Jones, C.E.T. 2013-02-23 15:24:13 PST
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.
Comment 14 Matthias Versen [:Matti] 2013-02-25 20:14:12 PST
*** Bug 844943 has been marked as a duplicate of this bug. ***
Comment 15 Joel Turner 2013-03-04 09:03:49 PST
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 ?
Comment 16 A Capesius 2013-03-14 23:20:47 PDT
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.
Comment 17 Scoobidiver (away) 2013-03-15 00:43:45 PDT
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.
Comment 18 A Capesius 2013-03-15 06:42:02 PDT
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.
Comment 19 A Capesius 2013-03-15 07:24:25 PDT
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.
Comment 20 Scoobidiver (away) 2013-03-15 08:02:00 PDT
A Capesius, file a new bug as comment 19 is not about the ability to fill in forms but being warned of unfillable forms.
Comment 21 Matthias Versen [:Matti] 2013-03-21 18:14:09 PDT
*** Bug 853355 has been marked as a duplicate of this bug. ***
Comment 22 Brendan Dahl [:bdahl] 2013-08-19 15:18:31 PDT
*** Bug 904997 has been marked as a duplicate of this bug. ***
Comment 23 LinK 2013-08-25 10:16:25 PDT
Do I understand correctly that this has been a known bug since March 2012?
Any idea when it will / or might ... be corrected?
Thanks
Comment 24 Phillip M. Jones, C.E.T. 2013-11-14 15:12:23 PST
(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)
Comment 25 Phillip M. Jones, C.E.T. 2014-03-26 11:49:04 PDT
Instead of  having people go to Aodobe. Make the built in solution Fill in forms
Comment 26 Alice0775 White 2014-03-26 12:27:54 PDT
*** Bug 988468 has been marked as a duplicate of this bug. ***
Comment 27 Matt Tagg 2015-02-16 19:22:17 PST
Would be great to have AcroForm support as a first step.
Comment 28 Brendan Dahl [:bdahl] 2015-11-23 15:17:07 PST
*** Bug 1226970 has been marked as a duplicate of this bug. ***
Comment 29 bugzilla 2016-01-29 09:07:07 PST Comment hidden (off-topic)
Comment 30 Yury Delendik (:yury) 2016-01-29 09:15:42 PST Comment hidden (off-topic)

Note You need to log in before you can comment on or make changes to this bug.