Created attachment 98978 [details]
test file

See attached document, field "180 deg" (left-middle of the page)
Pre-filled text appears properly, but if changed, text is not displayed for this field at all.

Evince devs tell me this is a poppler bug, but apparently even poppler bug can be dependent on the frontend...


Other bugs in the attached document:


Major:

* font size is changed when default text is changed. Try entering letters that have descenders: g,j,p,q,y -- they appear cut off
** this is especially bad in a list box -- try selecting item 3
** Note: in test2.pdf the font sizes are fixed - that works around this bug. However, there should be no reason to cut off some letters in "auto" mode.

* after editing, text field's gray border/outline is removed

* List box style is changed after editing. Before editing, highlighted value is blue; after editing it's black. Coupled with the bugs right above, it makes the input change significantly.
** Similarly, combo box loses its down arrow indicator

* hidden-but-printable field is editable

* single-line field with "spell check" flag does not highlight spelling mistakes (multi-line one does, KUDOS! most other frontends don't)

* fields with "rich text" flag don't accept rich text (test by copy/pasting HTML content from some page rendered in 
a browser -- tables, colors, links, formatting.. should be copied over)

* Field format specifications are ignored after any editing:
** all are rendered as plaintext -- no format decorations are applied
*** "number" should insert thousands separators and 2 digits after the decimal separator
*** "currency" setting often uses parentheses and red text to highlight negative amounts. This does not apply to positive amounts
*** "phone" should be rendered in a region-dependent way. In NA, it might be something like "+1(234)567-8901" 

** no validation is performed:
*** "number" should only allow digits and up to 1 decimal separator (can safely ignore thousands separators)
*** "phone" should only allow digits (this may be much more region-dependent, though)

* radio buttons are ignoring "reset form" on "mouse up" action -- so once a radio button is checked, it stays checked

* while zoomed in a lot, user can see "export value" of radio and check buttons -- in the document, they're all "Yes". There's no reason to show these to the user.


Minor:

* fields with "scrollable" flag don't seem to be scrollable in view mode (not sure if they should be; would they be actually scrollable or just have an image of a scroll bar?)

* no tooltips are displayed on any form fields

* 90- and 270- degree text fields look very inconvenient in edit mode - the editable field tries to fit into the rendered version, and ends up being tiny (just 3 letters-wide in the test case)

* While editing, user can't see exactly what the result will look like until she submits the changes.
** The thumbnail view is updated after a short delay -- that's helpful but of limited use, since thumbnail is usually so small and sometimes not shown by default.
** Check/radio buttons are visible in the actual document.. why not make them editable as-is instead of an ugly overlay? Evince does this already. Ideally, all fields should be editable in the style which will be rendered (or very close to it)

* Signature input is not recognized at all. If there are no plans to support this feature, maybe at least highlight it and issue a warning message explaining as much?


RFE:

* there's no way to highlight form fields (may be desired in a complicated document so user doesn't have to guess where the input fields are)
** required field should be highlighted with emphasis (usually pink/red shading)


For reference:
Poppler bug: https://bugs.freedesktop.org/show_bug.cgi?id=95391
Evince bug: https://bugzilla.gnome.org/show_bug.cgi?id=766398