1258963 - Buttons to go to the previous and next search results in the inspector

Status: RESOLVED WONTFIX

(DevTools :: Inspector, defect, P3)

Description

[albewyxb-1]

Attachment: Screenshot - 23_03_2016 , 08_35_50.jpg

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

- Right button mouse
- Inspector element
- Click in search box
- Write something that shows results



Actual results:

How do I go to the next result?
Why not go arrows to the next or previous result?

Comment 1

[albewyxb-1]

Windows XP SP3
FireFox 45.0.1

Comment 2

[Patrick Brosset <:pbro>]

The current way to cycle through results right now is to press ENTER. Repeatedly pressing ENTER will take you through the search results one by one.
We also have a bug on file to add ctrl+G and ctrl+shift+G to go the next and previous result (just like we do in the browser search tool): that's bug 1256658.

So if I understand correctly, this bug is about adding prev/next arrows next to the input field to be able to navigate through the results by clicking on these arrows.

Can you confirm this is the right idea?

If so, I'm going to needinfo Brian and Helen to ask for their takes on this. I know we want to make all our search boxes consistent across devtools, and they know more than me about this.

Comment 3

[albewyxb-1]

(In reply to Patrick Brosset [:pbro] from comment #2)
> So if I understand correctly, this bug is about adding prev/next arrows next
> to the input field to be able to navigate through the results by clicking on
> these arrows.
> 
> Can you confirm this is the right idea?
> 
> If so, I'm going to needinfo Brian and Helen to ask for their takes on this.
> I know we want to make all our search boxes consistent across devtools, and
> they know more than me about this.

Yes, I want the PREV search button or a quick key with the same effect. Is a disappointment not to go to the previous result. Sometimes, I have to inspect with Chrome instead of Firefox.

Comment 4

[Brian Grinstead [:bgrins]]

(In reply to albewyxb-1 from comment #3)
> (In reply to Patrick Brosset [:pbro] from comment #2)
> > So if I understand correctly, this bug is about adding prev/next arrows next
> > to the input field to be able to navigate through the results by clicking on
> > these arrows.
> > 
> > Can you confirm this is the right idea?
> > 
> > If so, I'm going to needinfo Brian and Helen to ask for their takes on this.
> > I know we want to make all our search boxes consistent across devtools, and
> > they know more than me about this.
> 
> Yes, I want the PREV search button or a quick key with the same effect. Is a
> disappointment not to go to the previous result. Sometimes, I have to
> inspect with Chrome instead of Firefox.

I was thinking that shift+enter navigated backwards in the results but I just double checked and that isn't implemented.  That would be a trivial bug to fix (add `event.shiftKey` here: https://dxr.mozilla.org/mozilla-central/source/devtools/client/inspector/inspector-search.js#110) and would at least make it possible to navigate in history in the mean time.

Comment 5

[Brian Grinstead [:bgrins]]

Filed Bug 1259060 to add the shift+enter keyboard shortcut.  Regarding adding buttons to the UI for the search box, I'll leave up to Helen but it seems reasonable as long as it's consistent across the tools.

The main tricky things for implementation here:

1) Within the tools we are supporting both XUL textbox (with .devtools-searchinput) and HTML input[type=search] (with .devtools-textinput).  Getting the styles and behavior the same on both of those could be tough depending on the designs.
2) Instead of some kind of web component or widget, the markup for the search boxes is directly in the pages and behavior added in each panel individually.  So right now each page would need to add the prev/next button as siblings to the search box, bind event handlers, keep their disabled attribute in sync with search state, etc.  I'd suggest we make some kind of component that somehow wraps up this UI and emits events when next / prev result are pressed / toggled with key shortcut.  It could be some kind of a shared react component, or a more traditional widget where we pass in the DOM node for the search box and it attaches this behavior.  The latter would be an easier migration since the boxes could remain in the markup.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Brian Grinstead [:bgrins] from comment #5)
> Filed Bug 1259060 to add the shift+enter keyboard shortcut.  Regarding
> adding buttons to the UI for the search box, I'll leave up to Helen but it
> seems reasonable as long as it's consistent across the tools.
> 
> The main tricky things for implementation here:
> 
> 1) Within the tools we are supporting both XUL textbox (with
> .devtools-searchinput) and HTML input[type=search] (with
> .devtools-textinput).  Getting the styles and behavior the same on both of
> those could be tough depending on the designs.
> 2) Instead of some kind of web component or widget, the markup for the
> search boxes is directly in the pages and behavior added in each panel
> individually.  So right now each page would need to add the prev/next button
> as siblings to the search box, bind event handlers, keep their disabled
> attribute in sync with search state, etc.  I'd suggest we make some kind of
> component that somehow wraps up this UI and emits events when next / prev
> result are pressed / toggled with key shortcut.  It could be some kind of a
> shared react component, or a more traditional widget where we pass in the
> DOM node for the search box and it attaches this behavior.  The latter would
> be an easier migration since the boxes could remain in the markup.

We were discussing this at the React components meeting and Brian asked me to provide a summary of my comments here:

* I support the idea of implementing the Search box as React component that is either rendered outside of the panel area (at the same level as panel tabs like Firebug) or inside the panel area (i.e. being reused by panels).

* Communication between the search box and the current panel through events sounds good to me. Both sides of the communication (search box <-> panel) need to know very little about each other when emitting/handling events.

* Firebug defines the following interface between the Search Box and panels (note that Firebug doesn't use events, but directly accessing props of the current panel):

- panel.searchable [bool] - Is the panel searchable? Should the search box be displayed?
- panel.search [function, callback] - The user just executed a search.
- panel.searchPlaceholder [string] - The placeholder text displayed in the search box.
- panel.getSearchOptionsMenuItems [array] - Get list of search options for the current panel (e.g. 'Search in Response bodies' in the Net panel)
- panel.searchText [string] - The current search text.
- panel.shouldIgnoreIntermediateSearchFailure [bool] - For non-immediate (automatic) searches, ignore search failures if the panel tells us to. This is used e.g. for HTML panel selector searches, where even if a typed string (".cla", say) doesn't match anything, an extension of it (".class") still could.
panel.panelNode

----

Panel's search() method:

/**
 * Called by the framework when panel search is used.
 * This is responsible for finding and highlighting search matches.
 *
 * @param {String} text String to search for
 * @param {Boolean} reverse Indicates, if search is reversed
 * @returns {Promise} resolved to true, if search matched, otherwise false
 */
search: function(text, reverse)
{
},

Here is the search box component in Firebug:
https://github.com/firebug/firebug/blob/master/extension/content/firebug/chrome/searchBox.js


Honza

Comment 7

[Helen V. Holmes (:helenvholmes) (:✨)]

I'm marking this as a WONTFIX. Hitting "Enter" to go to the next search result is a fairly search/result common pattern.

Comment 8

[rappeas]

i've never interacted with a search input using the enter key to go to next result. it actually took me several seconds to figure out how to get to next, and it feels awkward to me.

In addition, if the user moves the focus out of the search box, such as by clicking on the node in the markup, the user has to re-focus the search box such as by cliking and only then pressing enter to get to the next result. so not only does this require twice as many steps, but requires switching between keyboard and mouse to perform a single action. (ctrl-g and ctrl-shift-g also do not work unless the search input has focus.)

please reconsider adding previous, next buttons