Closed Bug 1537716 Opened 5 years ago Closed 5 years ago

Quantumbar: Suppress a11y focus for the auto-selected result

Categories

(Firefox :: Address Bar, defect, P1)

defect
Points:
3

Tracking

()

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 --- fixed

People

(Reporter: dao, Assigned: dao)

References

Details

Attachments

(1 file)

from bug 1522440 comment 8:

(In reply to Mark Banner (:standard8) from comment #7)

Since this might help with knowing where to start fixing browser_test_focus_urlbar.js, MarcoZ has pointed out that the current implementation of QuantumBar auto-focuses the first item as soon as someone starts typing in the urlbar. It should only auto-focus after the user has pressed the down arrow (or whatever to get to the results).

Yes, I'm aware. The suppressMenuItemEvent stuff in urlbarBindings.xml implements that.

Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Priority: -- → P1
Summary: Suppress a11y focus for the first auto-selected result → Quantumbar: Suppress a11y focus for the first auto-selected result

Comment on attachment 9052528 [details]
Bug 1537716 - Quantumbar: Suppress a11y focus for the auto-selected result.

How's this?

Attachment #9052528 - Flags: feedback?(mzehe)

Comment on attachment 9052528 [details]
Bug 1537716 - Quantumbar: Suppress a11y focus for the auto-selected result.

Standard8 is telling me that Marco is out sick. Will test this myself as well as I can, then request code review.

Attachment #9052528 - Flags: feedback?(mzehe)
Attachment #9052528 - Attachment description: Bug 1537716 - Quantumbar: Suppress a11y focus for the first auto-selected result. → Bug 1537716 - Quantumbar: Suppress a11y focus for the auto-selected result.
Summary: Quantumbar: Suppress a11y focus for the first auto-selected result → Quantumbar: Suppress a11y focus for the auto-selected result

Dao, could you explain the expected effects of this patch? I think I see what you're trying to do, but I've been testing in NVDA and I can't really hear the difference.

From the previous comments regarding suppressMenuItemEvent handling, I was expecting DOMMenuItemInactive/DOMMenuItemActive events to be fired somehow.

Flags: needinfo?(dao+bmo)

(In reply to Mark Banner (:standard8) from comment #4)

Dao, could you explain the expected effects of this patch? I think I see what you're trying to do, but I've been testing in NVDA and I can't really hear the difference.

The expected result is that when typing in the urlbar, the autoselected / heuristic result shouldn't get a11y focus and shouldn't be announced. Only when manually changing the selection it should be announced. Also, when changing the selection and then typing, a11y focus should return from the list to the input.

From the previous comments regarding suppressMenuItemEvent handling, I was expecting DOMMenuItemInactive/DOMMenuItemActive events to be fired somehow.

The richlistbox uses these events, we generally don't. We use the aria attributes instead.

Flags: needinfo?(dao+bmo)

So I've just tested this again and I can't see there's a difference.

For example,

  1. Enter a few characters (e.g. "tre")
  2. Let the voice audio stop
  3. Enter another character ("e")

I get: "e, unknown, combobox collapsed, list, tree search with google 1 of 10".

I did just manage to get it to a state where it didn't tell me the details for every character I entered, but I'm not sure what I did for that, and can't reproduce it.

It did seem to help some more of browser_test_focus_urlbar.js to be passing though.

James, as Marco is out, could you take a look at the patch here and see if it helping and I'm missing something?

Flags: needinfo?(jteh)

This does seem to work for me. Without the patch, the suggestions list items are reported every time I type. With the patch, the suggestion list items are only reported when I hit down arrow.

(In reply to Mark Banner (:standard8) from comment #6)

I get: "e, unknown, combobox collapsed, list, tree search with google 1 of 10".

That's concerning. It does indeed sound like this is breaking for you; I don't see how you could be missing something. It's just not the behaviour I see.

One thing worth noting is that search engine suggestions seem to be broken for me in local builds, even though I have them enabled. That could well make a difference if, for example, the async updating suggestions cause the accessible focus code to trigger.

Flags: needinfo?(jteh)

Thank you for testing Jamie, I think I must have been doing something wrong before. I just tried it again and it does indeed work a lot better (and search suggestions are working for me).

Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e5ebefeaf7f1
Quantumbar: Suppress a11y focus for the auto-selected result. r=Standard8
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Points: --- → 3
Blocks: 1542099
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: