1155483 - Netmonitor search input should be focused immediately

Status: NEW

(DevTools :: Netmonitor, defect)

Description

[Dane MacMillan [:danemacmillan]]

Clicking on the "Network" tab should automatically set focus to the new search input at the bottom of the panel, next to the predefined filters. For one, there's no concern about stealing focus from the browser document, because clicking on the "Network" tab has already moved the focus from the document to the Developer Tools "Network" tab. Secondly, it just makes sense: a typical visit to the "Network" tab will consist of skimming over the assets, scrolling, not finding anything, then possibly clicking a predefined filter, and scrolling some more. With search now available, I just want to use search. When I hit the "Network" tab, the next thing I want to do is start typing; I do not want to then move the cursor to the impossibly small and retracted search filter input box, possibly triggering my hidden OS application menu, moving the cursor away so it can disappear again, then meticulously hover over the search filter input box again, then clicking, then typing. There is much to gain from automatically focusing on the search filter input box and absolutely nothing to lose.

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I think I'd prefer to ship as-is and keep this bug around for a followup.

Dane: thanks for logging this and providing a well-thought-out use case. What I'm hesitant about is the automagic quality to the behaviour you're suggesting. To review:

* currently we focus the list itself so it can be navigated with the up/down arrow keys, and filtering can be engaged by hitting ctrl+f, the universal binding for 'Search here'

I like this, it's consistent with most of the rest of the tools. The one exception is of course the console, but that gets special-cased because input in the console is (obviously) the entire purpose.

I think we also need to consider different types of users based on how they interact with the tools - I suspect most users use some combination of keyboard input and clicking around - but some users definitely only use the keyboard unless forced to do otherwise and so automagic behaviours around keyboard focus can be jarring to them.

None of this is science, and I don't necessarily disagree with you, but I do think both that what we have now is pretty good, and it doesn't feel to me like we have enough feedback to make this call just yet.

Comment 2

[Dane MacMillan [:danemacmillan]]

Thanks for getting back to me. Would it be technically possible to bind events for the up/down directional keys AND automatically set focus to the search filter? I'm not certain how the event binding is handled in the Developer Tools, but if it's anything like standard JavaScript, I think that could be achieved. One possible issue with that could be if it's ever intended that the search filter also remember history (and cycling through is done with the directional keys à la standard terminal behaviour), which in that case makes binding the up/down directional keys in the search filter in conflict.

I'm just throwing ideas out. I'm happy to find out the cmd+f shortcut works.

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Again, thanks for the feedback, and I suspect you're right about being able to handle various inputs in that way. We'll keep this bug on the backlog for now.