1633285 - Hard to debug :focus effects in inspector

Status: UNCONFIRMED

(DevTools :: Inspector, enhancement, P3)

Description

[Glenn Linderman]

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

Steps to reproduce:

Open a menu by clicking an element, thus changing the element's focus. Using :focus and :focus-within features, the menu stays open while nagivating, but closes when focus is changed to outside the original element or its menu.

While the menu is open, attempt to view, in DevTools, the CSS for the focused element.

Actual results:

Well, if Inspector is already viewing the focused element, nothing happens; the CSS displayed is still that of the element before it was focused.

If the Inspector is not already viewing the focused element, clicking in Inspector to navigate, switches the focus away from the focused element.

Expected results:

It would be really useful for debugging, if the Inspector responded to changes in :focus in the page, and updated the displayed CSS for the element to reflect those changes.

(I think this problem has existed for several releases, but I've only just now codifed it to be able to submit a bug report.)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Glenn Linderman]

Attachment: focus.html - test case

Open the test case in the browser, Open DevTols to Inspector, navigate so that the <div class=inspectme> element is the selected element in the inspector.

Observe that the CSS panel shows "display: none;" for this element.

Move the mouse to the browser window, and click "I'm the menu button". Notice how the HTML panel changes to show that "inspectme" is now a grid, but the CSS panel remains showing "display:none;".

While this is a trivial case, the far more complex CSS in my site cannot be seen in similar circumstances, making it hard to debug.

Comment 3

[Julian Descottes [:jdescottes]]

Hi,

Thanks for filing! You are correct that the rules panel doesn't update dynamically when the focus moves to the <div class=menu> element.

Alternatively, you can toggle the focus state directly on the element by either right clicking on the element in the Inspector and using the "Change Pseudo-class" menu. Does that help here? You can also toggle those states if you click on ":hov" in the Rules panel.

Otherwise, it seems the test page highlights a webcompat issue related to button click and focus, so just a quick word about this. Firefox is following macos specifications here and not moving the focus to the button on click, whereas Chrome is not (see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus).

For now I will triage this as an enhancement, since states can be toggled and debugged, but happy to discuss more about this.

Comment 4

[Glenn Linderman]

Attachment: focus.html - test case with tabindex

So I forgot to include the tabindex in my test case... because it wasn't work, I thought It was good enough, but I did, in fact, have tabindex on every .menu item in my real code... which are all DIV not BUTTON.

I'm not sure I'd have ever thought to right click to find the change pseudo-class menu, but that does, in fact let me see the CSS I couldn't see before, and also affects the display in the HTML page. So that you for educating me in that regard, this helps, but it is certainly not as useful in figuring out how things actually work dynamically. Inspecting a particular element, and having the Inspector's CSS panel update dynamically, like the HTML panel does (adding the GRID icon, for example) when clicking around in the main window would be far more useful. I note that the appearance and disappearance of the GRID icon as I click in different spots, is reflecting a change to CSS, even though the CSS panel is not updating to show the "display: grid;" CSS rule, or any of the others. So the inspector is being half-responsive to CSS changes, but not fully responsive. For this reason, I would consider this to be a bug, to make the Inspector show consistent information across its panels, rather than an enhancement. Showing inconsistent information is extremely confusing.

I don't understand what you mean by "follow the macos specification". W3C is the standards organization, not Apple. And the page you referred me to looks seriously out of date, talking about Windows 8.1 and Firefox 30, whereas these days Windows 10 and Firefox 76 are much more interesting. Further, Firefox mobile isn't listed (although it is seriously behind times, at branch 68). Neither is Firefox Preview listed.

Note that in my example, I actually have cursor events turned off for "I'm the menubutton": the BUTTON is really only for appearance, and the click should be seen by the DIV (especially now that I've updated the test case with tabindex) and it should get the focus.

The other buttons (for the example) do not have cursor events turned off: It is not clear what should happen regarding focus, nor regarding "focus within" for the DIV once one of those buttons is clicked. I do note that for Firefox branch 76 on Windows 10 today, that clicking the other buttons causes the text within the button to get an outline that looks extremely like the default focus outline. But I can't tell from Inspector whether they are getting focused or not, because the rules don't show up dynamically when I click.

Comment 5

[Glenn Linderman]

So this "Change pseudo-class" workaround for not updating the rules seems to have changed. While I consider it a poor workaround, I was able to use it for a while.... and then went off to other parts of the code. Coming back to debug now, it seems that one can no longer set multiple items to have "focus-within", preventing the display of nested menu items with the visible rules.

The interface would be far better if one could instead set "focus" on a particular element, and have the DevTools automatically propagate "focus-within" up the tree.

Of course, it would be even better, if the DevTools, when open, updated the rules as the user moused around inside the browser window, as per the original report for this bug.