1544773 - Activating disclosures in the dev console with NVDA forcefully redirects focus to the console input

Status: RESOLVED FIXED

(DevTools :: Console, defect, P3)

Description

[Dickson Tan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

CC: @jcsteh

With NVDA running:

1. Paste the following code into the console.

console.groupCollapsed("test");
console.log("some content");
console.groupEnd();

2. Press space on the collapsed button to expand its contents, while still in browse mode.

Actual results:

Focus is always forcefully moved to the text input. The disclosure does expand.

Expected results:

The disclosure is expanded, and focus does not move unexpectedly.

Comment 1

[Dickson Tan]

I'd like to take a stab at solving this. I've found the CollapsedButton component, and the actions and reducers triggered when the disclosure is toggled, but haven't yet found what is responsible for redirecting focus back to console input.

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

Hey Dickson.
My guess is that it's the onClick event in devtools/client/webconsole/components/App.js#82-132 that put back the focus on the input.

Comment 3

[Dickson Tan]

Thanks Nicolas.

Jamey investigated this when I filed this issue in the NVDA repository, and his guess is that this is intended behaviour, since otherwise mouse users who click on disclosures will have focus forced from text input to the button.

Note that this does work if the screen reader is in focus mode, but is an extra step.

Will try to think of a situation to differentiate these 2 scenarios, or maybe only conditionally restore focus if it was already on input.

Comment 4

[James Teh [:Jamie]]

(In reply to Dickson Tan from comment #3)

Jamey investigated this when I filed this issue in the NVDA repository, and his guess is that this is intended behaviour, since otherwise mouse users who click on disclosures will have focus forced from text input to the button.

I haven't looked at the code. However, assuming I'm correct about this (and assuming we don't need the mousedown or drag events for any other reason), you could:

1. Get rid of the focus behaviour in the click event.
2. Call event.preventDefault() in the mousedown event. This will prevent the default focus behaviour when the mouse is clicked, thus preventing the focus annoyance for mouse users in the first place.

Comment 5

[Dickson Tan]

Thanks Jamie, that solution worked wonderfully:

• using event.preventDefault in the disclosure's onmousedown event. Btw, I can't seem to find documentation anywhere on MDN about the mousedown event causing elements to gain focus, so am wondering where that is documented. Also, if NVDA is in browse mode and I hit space on a button, does it simulate an onmousedown?
• Preventing the onclick from bubbling up to the parent app.js component, which redirects focus when it receives an onclick.

This behaviour will occur on other components in the output area as well, but I haven't ran into other examples like this where it is problematic.

I'm also trying to open an MR, but am not sure how to go about doing so. Do I need to create a new branch for the feature like in git?

Comment 6

[Dickson Tan]

Some other misc questions:

• When fixing this, I had to close firefox, and run mach build, then restart firefox again to see my changes, which is a really long feedback cycle. Is there a way of running it with live reload support?
• Is there a way of printing out stuff to the console from a component in dev tools as a debugging aid? Console.log doesn't seem to work at all.

Thanks a lot for the guidance :)

Comment 7

[James Teh [:Jamie]]

(In reply to Dickson Tan from comment #5)

Also, if NVDA is in browse mode and I hit space on a button, does it simulate an onmousedown?

It simulates a click, which gets mapped to mousedown, click and mouseup events in the browser.

I'm also trying to open an MR, but am not sure how to go about doing so. Do I need to create a new branch for the feature like in git?

This needs to be submitted to mozilla-central, so you'll need to use Phabricator. See https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html

(In reply to Dickson Tan from comment #6)

• When fixing this, I had to close firefox, and run mach build, then restart firefox again to see my changes, which is a really long feedback cycle. Is there a way of running it with live reload support?

I don't think you can live reload. However, because you're not modifying any binary code, you can do:
mach build faster
which will just rebuild the non-binary stuff (js, xul, html, etc.). That is much faster. You still need to restart Firefox, though.

• Is there a way of printing out stuff to the console from a component in dev tools as a debugging aid? Console.log doesn't seem to work at all.

It might get logged to the browser console (control+shift+j)? I'm not sure, but others here might know.

Comment 8

[Dickson Tan]

Attachment: Bug 1544773 - fix clicking on disclosures in the console redirecting focus to input. r=nchevobbe!

The top-level App component forcefully resets focus to the console input when something in the output gains focus, e.g disclosure toggles, and the clear output button.While this is useful for mouse users when typing, it breaks reading flow for screen reader users when reviewing output, being sent back to input when interacting with disclosures.

This commit prevents the unwanted focus behaviour when clicking by suppressing it in an onMouseDown, and prevents the click event from bubbling to the App component so focus doesn't get reset.

Comment 9

[Dickson Tan]

I've just submitted a patch to phabricator, let me know if I missed out any steps.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1127060b0433
fix clicking on disclosures in the console redirecting focus to input. r=nchevobbe

Comment 11

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/1127060b0433