1328003 - Provide better focus styling for markup view in the inspector that clearly indicates when the tree is focused.

Status: NEW

(DevTools :: Inspector, defect, P2)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Open devtools -> inspector
2. Click on text "<body" in markup
3. Press Escape to open split console

AR:  No visible action
ER:  Split console should open

This is a regresssion, it seems.

Comment 1

[YF (Yang)]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bc6334aea116516a4f639cf1fd0ead741968624b&tochange=cd45f64c6d68334eff08bbf52a4188b25b7d17cb

cd45f64c6d68	Yura Zenevich — Bug 1242694 - improving inspector markup view accessibility (semantics and keyboard). r=gl

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Yura can you take a look?

Comment 3

[Yura Zenevich [:yzen] (please use "needinfo")]

Just to confirm, when the body is clicked, the keyboard focus shift onto the body tag? I have a feeling that what happens here - the markup view takes over the focus and we step into the widget (markup view). Escape does not propagate any more to the window and instead results in the widget container to focus again). I don't believe it is a bug, tbh (in the sense that it's not a regression but that the behavior has changed). It's unfortunate that the focus is still barely visible too..

Comment 4

[Patrick Brosset <:pbro>]

I tend to agree with Yura here, this seems like an intended behavior.

As I understand it, there are 2 levels: the parent/container/widget level (i.e. the markup-view) which is involved in the global tab navigation of the inspector that allows to tab from e.g. the search field, to the markup-view, to the breadcrumb, to the sidebar tabs, etc.
And the child level (i.e. a single node within the markup-view).

It seems like the intended behavior is for enter to go from parent to child, and escape to go from child to parent.

However, it doesn't look like the other panels do this. For instance when the rule-view gains focus, pressing enter doesn't do anything, and if you focus a single property, pressing escape doesn't revert the focus back to the rule-view container, but opens the console immediately.

I think for accessibility reasons, this enter/escape behavior makes sense. This is why it was implemented. But it conflicts with the fact that the split console is always one keypress away, wherever you may be.

Yura: could we use another key to focus back the markup-view?

Comment 5

[Yura Zenevich [:yzen] (please use "needinfo")]

I was hoping to get to keyboard a11y at some point for other panels/containers (such as ruleview) where focus is handled internally similarly to markup view (computed/box model stuff is something Nancy already started working on and will be interning with us starting next tuesday. It could be a good couple of bugs to work on for her). This would make it consistent across these widgets. So I wonder if that would be an acceptable way forward?

Comment 6

[Patrick Brosset <:pbro>]

Let's ask Brian.
Brian, please see comment 4 for context. As the console owner, what do you think about this?

Comment 7

[Brian Grinstead [:bgrins]]

(In reply to Patrick Brosset <:pbro> from comment #6)
> Let's ask Brian.
> Brian, please see comment 4 for context. As the console owner, what do you
> think about this?

It's unfortunate that ESC is the convention for toggling the split console.  But since that's how it is it does feel best if it is a single press away, unless if there is some other state that first needed to be dismissed like editing an attribute, closing a popup, etc.  And if I'm primarily a mouse user I probably don't want / am confused by focusing up to the frame after just clicking on an element.

I don't want to break the specified behavior at https://bugzilla.mozilla.org/show_bug.cgi?id=1242694#c4 though - it seems like the two things are in direct conflict.  Are we going to have to pick one or the other here?  Or is there some easy way to determine if the current focused element was arrived at via the keyboard and do the 'move focus to frame behavior' in that case and otherwise do 'open split console'?

Comment 8

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to (Unavailable until Apr 3) [:bgrins] from comment #7)
> (In reply to Patrick Brosset <:pbro> from comment #6)
> > Let's ask Brian.
> > Brian, please see comment 4 for context. As the console owner, what do you
> > think about this?
> 
> It's unfortunate that ESC is the convention for toggling the split console. 
> But since that's how it is it does feel best if it is a single press away,
> unless if there is some other state that first needed to be dismissed like
> editing an attribute, closing a popup, etc.  And if I'm primarily a mouse
> user I probably don't want / am confused by focusing up to the frame after
> just clicking on an element.
> 
> I don't want to break the specified behavior at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1242694#c4 though - it seems
> like the two things are in direct conflict.  Are we going to have to pick
> one or the other here?  Or is there some easy way to determine if the
> current focused element was arrived at via the keyboard and do the 'move
> focus to frame behavior' in that case and otherwise do 'open split console'?

I believe there is no easy way to know unless both click's and focus is tracked and we infer from both events happening that it came via mouse. 

I think there might be more complications where users click on the inspector and then tab through (editing) or something like that, and maybe click again (a combination of both).. It would be hard to make a reliable call about what should happen in that case.

Perhaps there's another way of better highlighting that the inspector is currently interactive that would put it in a category of widgets that need to be dismissed..

I realize Brian is away for some time, Patrick, do you have any thoughts about how to proceed ?

Comment 9

[Patrick Brosset <:pbro>]

I think we should make it more visible that the markup-view has entered a focus state. Right now it's not very easy to see what is currently focused, and therefore, it's hard to understand the enter/escape logic to go in and out of widgets.
So if we did make the focus outline stand out a little more, then that would address this problem, and also make it a lot easier for people to understand why just 1 ESC keypress isn't enough.
So, my point is, let's keep the double escape in this case to open the split console. I can't think of any other solution.

Comment 10

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to Patrick Brosset <:pbro> from comment #9)
> I think we should make it more visible that the markup-view has entered a
> focus state. Right now it's not very easy to see what is currently focused,
> and therefore, it's hard to understand the enter/escape logic to go in and
> out of widgets.
> So if we did make the focus outline stand out a little more, then that would
> address this problem, and also make it a lot easier for people to understand
> why just 1 ESC keypress isn't enough.
> So, my point is, let's keep the double escape in this case to open the split
> console. I can't think of any other solution.

Thanks, I'm on the same page. I would also like to experiment with focus highlighting that is not just outline, but a background color too. See examples on https://www.gov.uk/.
Ill take this bug but can't promise getting to it asap.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix for 53, fix-optional for 54, minor carryover regression.

Comment 12

[Nicolas Chevobbe [:nchevobbe]]

We do have a focus indicator but only on focus-visible . We could do what the accessibility tree is doing and style the selected node differently when the markup view isn't focused