1723615 - [XFA & AcroForm] Radio buttons are focused in the wrong order

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Morgan Reschenberg [:morgan]]

+++ This bug was initially created as a clone of Bug #1718528 +++

Tested on:

MacOS 11.2

Steps:

1. Launch the browser.
2. Flip the pdfjs.enableXfa to true.
3. Load https://bug1718528.bmoattachments.org/attachment.cgi?id=9229184
4. Using the keyboard only, navigate to any checkbox or radio button
5. Activate the control

Actual result:

The control is skipped during navigation, the cursor instead moves to the next input box. The controls cannot be activated

Expected result:

The controls should be navigable and able to be checked/unchecked.

Comment 1

[Morgan Reschenberg [:morgan]]

Note: this is broken for me with the following prefs (used to accommodate mac focus abnormalities) but is also broken without the prefs

System Preferences > Keyboard > Shortcuts > (checked) Use keyboard to move focus between controls

About:config > accessibility.tabfocus = 7
About:config > accessibility.tabfocus_applies_to_xul = true

Comment 2

[Marco Castelluccio [:marco]]

It looks like the checkboxes are not focused, but actually they are (the order of focus with the keyboard is not the same as it's shown on screen).

On Linux, the checkboxes are not activable after navigating with the keyboard on AcroForm forms either, e.g. on https://tcpdf.org/files/examples/example_054.pdf or https://raw.githubusercontent.com/mozilla/pdf.js/master/test/pdfs/annotation-button-widget.pdf.
Could you confirm?

Comment 3

[Morgan Reschenberg [:morgan]]

(In reply to Marco Castelluccio [:marco] from comment #2)

It looks like the checkboxes are not focused, but actually they are (the order of focus with the keyboard is not the same as it's shown on screen).

On Linux, the checkboxes are not activable after navigating with the keyboard on AcroForm forms either, e.g. on https://tcpdf.org/files/examples/example_054.pdf or https://raw.githubusercontent.com/mozilla/pdf.js/master/test/pdfs/annotation-button-widget.pdf.
Could you confirm?

On Mac, I can activate checkboxes on the acroform, even though focus doesn't follow.
I cannot activate or focus radio buttons.

All of these operations are possible in acrobat, which is why this bug blocks the Xfa one.

Comment 5

[Marco Castelluccio [:marco]]

I filed bug 1723931 for the bad traversal order, and I morphed this bug into the problem of not being able to activate or focus radio buttons.

To summarize, the three issues we have with keyboard navigation are:

• bad traversal order in some cases (bug 1723931);
• no focus indicator on checkboxes and radio buttons (bug 1718528);
• no focus and impossibility to activate for radio buttons (this bug).

Comment 6

[Marco Castelluccio [:marco]]

Actually, if I keep tabbing and tabbing and then press enter, I am able to activate radio buttons too.
Maybe the combination of bug 1723931 and bug 1718528 are making us see this bug?

Comment 7

[Marco Castelluccio [:marco]]

Turns out the Canadian PDF from comment 0 is buggy (funny enough, those are the most important XFA PDFs we aim to support...), that's why this got confusing.

We can test with this one: https://bug1723931.bmoattachments.org/attachment.cgi?id=9234760.

It looks like radio buttons are focused (without focus indicator, but that's bug 1718528) and they can be activated, but they are focused in the wrong order (they are only focused if you keep pressing tab after you go through all other fields in the PDF).

Comment 8

[James Teh [:Jamie] (away returning 28 Jan)]

Morgan, can you confirm that you can eventually reach the radio buttons if you keep tabbing? If so, I'm wondering whether we can downgrade this to access-s3, since a user can still get to them, albeit somewhat confusingly and annoyingly.

Comment 9

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/13875

Comment 10

[Morgan Reschenberg [:morgan]]

Oh gross, yeah I can get to them after going through the whole document :(
Not sure if this is the same on other platforms, but the reason I didn't notice this at first is (let's say this document has 3 pages and there are some radio buttons on page 1), you don't get "scrolled up" to page 1 after you finish the document and tab to the "next" thing. There seems to be an empty item getting (invisible) focus between the end of the doc and starting the radio buttons.

Super weird! but yeah, technically a keyboard user can reach them.
:Jamie your call on severity :)

Comment 11

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub master push: https://github.com/mozilla/pdf.js/commit/834e475e1dfebf05aceebb4a6f5f4d798464d53a

Commit merged into master by GitHub
Authored by calixteman (calixteman)

Comment 12

[James Teh [:Jamie] (away returning 28 Jan)]

(In reply to Morgan Reschenberg [:morgan] from comment #10)

Not sure if this is the same on other platforms, but the reason I didn't notice this at first is (let's say this document has 3 pages and there are some radio buttons on page 1), you don't get "scrolled up" to page 1 after you finish the document and tab to the "next" thing.

This is somewhat academic now that there's a fix, but...
Considering this point (plus the fact that the document might be many pages long), I agree with the original assessment of an access-s2. A keyboard user probably won't know that they can keep tabbing forever to find radio buttons, unless that workaround were documented somewhere (which might be an acceptable hack to unblock release if we hadn't been able to fix this in time).

Comment 13

[James Teh [:Jamie] (away returning 28 Jan)]

:bdahl, now that bug 1724461 is closed, can this be closed as well? That is, is there any reason this fix wouldn't have been included in that update?

Comment 14

[Daniel Bodea [:danibodea]]

Unfortunately, this cannot be closed since the order in which the fields are focused is wrong in the case of some other PDFs.
The PDF in comment 0 is indeed broken by itself considering that Adobe Reader shows the same wrong highlight order (by "Tab-ing" through it).

I will provide another example of a PDF that shows an incorrect order of focus in Firefox, but not in Adobe:
https://bug1671648.bmoattachments.org/attachment.cgi?id=9182033

Will provide others if found while the preliminary testing session.

Comment 15

[Daniel Bodea [:danibodea]]

Attachment: FormSolicitudDerechosRGPD-PURE-XFA.pdf

I have to mention that this issue is not specific to radio buttons or checkboxes, but to all input fields. I have attached another PDF that reproduces the issue in Firefox, but not in Adobe (incorrect focus/visible highlight by keyboard navigation).

Comment 16

[Daniel Bodea [:danibodea]]

I'm sorry if I made this even more confusing!
Doing my best to understand and clear it up...

Comment 17

[Jonas Jenwald [:Snuffleupagus]]

(In reply to James Teh [:Jamie] from comment #13)

That is, is there any reason this fix wouldn't have been included in that update?

The patch landed in bug 1724461, let's just close this one as fixed :-)

(In reply to Bodea Daniel [:danibodea] from comment #14)

Unfortunately, this cannot be closed since the order in which the fields are focused is wrong in the case of some other PDFs.

If this bug, as reported in bug 1723615 comment 0, is now fixed we should just close it. Please note that having subtly different issues reported in the same bug generally makes tracking where things actually landed much more difficult.

Comment 18

[Daniel Bodea [:danibodea]]

I don't mean to be inconsiderate, but this should have been closed as Invalid or at least Worksforme.
In any case, the steps presented in comment 0 are not reproducing, so Resolved by is fine by me.

I've logged another bug for the issue this bug was supposed to address in the first place: bug 1726173.

Comment 19

[Brendan Dahl [:bdahl]]

(In reply to James Teh [:Jamie] from comment #13)

:bdahl, now that bug 1724461 is closed, can this be closed as well? That is, is there any reason this fix wouldn't have been included in that update?

Yeah, this can be closed. I noticed some discrepancies in tab order for Firefox vs Acrobat, but I'll file a new bug for that.

Comment 20

[Daniel Bodea [:danibodea]]

@Brendan: What do you mean by "tab order"?
Does the bug mentioned in comment 18 cover that?
Thanks!

Comment 21

[Brendan Dahl [:bdahl]]

Yes, that covers it. Thanks!

Comment 22

[Daniel Bodea [:danibodea]]

Setting as verified based on the above comments.