In-content prefs should trap focus (tab key navigation) in subdialogs and the browser UI when they are open (it should not be possible to focus items in the main page)

VERIFIED FIXED in Firefox 38

Status

()

P3
normal
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: alice0775, Assigned: Gijs)

Tracking

({access})

Trunk
Firefox 39
x86_64
Windows 7
access
Points:
8
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(firefox38+ verified, firefox39 verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Steps To Reproduce:
1. Open Preferences and sub-dialog
2. Press TAB key several times

Actual Results:
The focus element moves to main preferences which is behind of sub-dialog now

Expected Results:
The focus element should be only in between the browser UI and the sub-dialog
(Assignee)

Updated

4 years ago
Flags: firefox-backlog+
Marco, do you know if there is a sane "web" way to constrain tab selection to items in a given container (element)? Of course, we could steal the tab key, but I'd prefer something that felt less hacky... :-\
Flags: needinfo?(marco.zehe)
Keywords: access

Comment 2

4 years ago
Nope, there is only the way of specifically controlling the tab key when it reaches the last element, or the first (when shift-tabbing), and define where it should go next. This is what we get when putting stuff in content that used to be modal, we have to make sure of the modaility ourselves. Every web author faces this when constructing overlays, popups or dialogs and wants to implement full keyboard support.
Flags: needinfo?(marco.zehe)

Comment 3

4 years ago
It seems bug 840640 (the dialog element) and bug 921504 (inert attribute) are relevant here. In the absence of such support, it seems setting tabindex=-1 on all interactive elements except those in the dialog is the necessary workaround.
Priority: -- → P3
Points: --- → 8
(Assignee)

Updated

4 years ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 39.1 - 9 Mar

Updated

4 years ago
Flags: qe-verify?

Updated

4 years ago
Iteration: 39.1 - 9 Mar → 39.2 - 23 Mar
(Assignee)

Updated

4 years ago
Summary: Navigating by TAB key, it should be only in between the browser UI and the sub-dialog → In-content prefs should trap focus (tab key navigation) in subdialogs and the browser UI when they are open (it should not be possible to focus items in the main page)
Created attachment 8575965 [details] [diff] [review]
prevent focus from leaving the dialog for anything but the browser UI,

This might fix bug 1128175 while we're here.
Attachment #8575965 - Flags: review?(jaws)
(In reply to :Gijs Kruitbosch from comment #5)
> Created attachment 8575965 [details] [diff] [review]
> prevent focus from leaving the dialog for anything but the browser UI,
> 
> This might fix bug 1128175 while we're here.

Nope. Still, patch works otherwise.
Comment on attachment 8575965 [details] [diff] [review]
prevent focus from leaving the dialog for anything but the browser UI,

Egh, nope, not on Windows. I love focus, I really do.
Attachment #8575965 - Flags: review?(jaws)
Created attachment 8575997 [details] [diff] [review]
prevent focus from leaving the dialog for anything but the browser UI,

Now with the right window and taking into account the node might be anonymous, esp. for dialog buttons.
Attachment #8575997 - Flags: review?(jaws)
(Assignee)

Updated

4 years ago
Attachment #8575965 - Attachment is obsolete: true
Comment on attachment 8575997 [details] [diff] [review]
prevent focus from leaving the dialog for anything but the browser UI,

Review of attachment 8575997 [details] [diff] [review]:
-----------------------------------------------------------------

Built and tested on Windows 8.1 and it works good.

::: browser/components/preferences/in-content/subdialogs.js
@@ +214,3 @@
>      this._overlay.style.opacity = ""; // XXX: focus hack continued from _onContentLoaded
> +
> +    this._trapFocus();

_untrapFocus is called from _removeDialogEventListeners. It would be nice if _trapFocus was called from _addDialogEventListeners so that we have symmetry.
Attachment #8575997 - Flags: review?(jaws) → review+
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> Comment on attachment 8575997 [details] [diff] [review]
> prevent focus from leaving the dialog for anything but the browser UI,
> 
> Review of attachment 8575997 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Built and tested on Windows 8.1 and it works good.
> 
> ::: browser/components/preferences/in-content/subdialogs.js
> @@ +214,3 @@
> >      this._overlay.style.opacity = ""; // XXX: focus hack continued from _onContentLoaded
> > +
> > +    this._trapFocus();
> 
> _untrapFocus is called from _removeDialogEventListeners. It would be nice if
> _trapFocus was called from _addDialogEventListeners so that we have symmetry.

As discussed on IRC, it needs to have the content document for the frame, that's why it's in onLoad.

Try push, as fx-team is closed anyway:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=abf6376ccbb9
remote:   https://hg.mozilla.org/integration/fx-team/rev/3aea1d4e06c5
Flags: qe-verify? → qe-verify+
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/3aea1d4e06c5
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 39
Comment on attachment 8575997 [details] [diff] [review]
prevent focus from leaving the dialog for anything but the browser UI,

Approval Request Comment
[Feature/regressing bug #]: in-content prefs
[User impact if declined]: confusing keyboard accessibility on the in-content prefs
[Describe test coverage new/current, TreeHerder]: nope :-(
[Risks and why]: medium-low; is unlikely to make the keyboard-a11y situation worse, should go a long way to making it better
[String/UUID change made/needed]: nope
Attachment #8575997 - Flags: approval-mozilla-aurora?
QA Contact: camelia.badau
Comment on attachment 8575997 [details] [diff] [review]
prevent focus from leaving the dialog for anything but the browser UI,

approving uplift in the hopes it does make keyboard a11y better.
Attachment #8575997 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox38: --- → affected
tracking-firefox38: --- → +
Verified fixed on Windows 7 64bit and 32bit using latest Nightly 39.0a1 (buildID: 20150315030236).
Status: RESOLVED → VERIFIED
status-firefox39: fixed → verified
Verified fixed on Windows 7 64bit using latest Aurora 38.0a2 (buildID: 20150322004013).
status-firefox38: fixed → verified

Updated

3 years ago
Depends on: 1214293
You need to log in before you can comment on or make changes to this bug.