Bug 17126 – Web Inspector: selectors in the Styles pane should trigger a search for that selector when clicked

• Component: Web Inspector
• Status: RESOLVED FIXED

[Adam Roben (:aroben)]

Now that we've fixed bug 16234 we should linkify selectors in the Styles pane so that when you click them the selector is placed in the Inspector's search field and a search is performed. This will make it easy to see all the nodes that match a particular selector and therefore have those styles applied.

[Adam Roben (:aroben)]

<rdar://problem/5718859>

[Joseph Pecoraro]

Created attachment 41549 [details]
[PATCH] Perform Search when Single Clicking a Selector

This turns out to be really awesome!  Great job whoever implemented searching!

[Joseph Pecoraro]

Video Showing What this feels like: (although my commentary is horrible!)
http://screencast.com/t/rFBUL7vy2d

[Joseph Pecoraro]

Created attachment 41550 [details]
[PATCH] Perform Search when Single Clicking a Selector

Piggy backing a little fix for editing attributes at the same time.

[Joseph Pecoraro]

Landed in http://trac.webkit.org/changeset/49904
r49904 = 0b3e4bd8da685736976258b07c4234273878c9f9

[Pavel Feldman]

A small follow-up comment.

As of today, search is implemented somewhat inefficient. It is going to search through the entire document and push the results into the frontend, no matter whether nodes are reached there or not. So it'll be slow for large documents.

We can optimize it either in general case (for search to respond with ids of found elements and asynchronously query for the next ones), or for this case only where we make search return results the nodes that are already in frontend (i.e. superset of the visible ones).

One usability nit: there is no notion of the current search result and hence using the search field and highlight is a bit confusing. I am also not a fan of the approach where selecting a non-selectable element is populating the search field and is not cleaning it up on losing selection.

Due to the reasons above, Eclipse has a feature called "Mark occurrences". It is a toggle toolbar button that enables a mode where whatever you touch (move cursor to) is searched over the document and is being highlighted. When you move caret to another location it'll wait a bit and select occurrences of the new thing.

[Joseph Pecoraro]

(In reply to comment #6)
> One usability nit: there is no notion of the current search result and hence
> using the search field and highlight is a bit confusing.

This is true. Maybe add some kind of pointer like how the Scripts Debugger indicates the current statement.  Or adding a style class.  On problem I had is if the current node is selected and highlighted. This is easily solvable with CSS.  A quick example:
http://grab.by/b0A

  :focus .outline-disclosure li.selected.highlighted .selection {
      background-color: rgb(255, 153, 0);
  }


> I am also not a fan of
> the approach where selecting a non-selectable element is populating the search
> field and is not cleaning it up on losing selection.

I don't follow this."Selecting a non-selectable element"?  I could see how not cleaning up the search field could be annoying.


> Due to the reasons above, Eclipse has a feature called "Mark occurrences". It
> is a toggle toolbar button that enables a mode where whatever you touch (move
> cursor to) is searched over the document and is being highlighted. When you
> move caret to another location it'll wait a bit and select occurrences of the
> new thing.

This sounds good to me.  Hover over (instead of clicking) a selector to highlight the nodes it affects. Also, its worth noting that WebInspector.panels.elements.performSearch(selector) works without populating the search field, but it doesn't show the # of results found.  We could probably clean all of this up when improving searching like Pavel mentioned in his comment.

[Joseph Pecoraro]

> > Due to the reasons above, Eclipse has a feature called "Mark occurrences". It
> > is a toggle toolbar button that enables a mode where whatever you touch (move
> > cursor to) is searched over the document and is being highlighted. When you
> > move caret to another location it'll wait a bit and select occurrences of the
> > new thing.
> 
> This sounds good to me.  Hover over (instead of clicking) a selector to
> highlight the nodes it affects. Also, its worth noting that
> WebInspector.panels.elements.performSearch(selector) works without populating
> the search field, but it doesn't show the # of results found.  We could
> probably clean all of this up when improving searching like Pavel mentioned in
> his comment.

Here is the experiment:
http://screencast.com/t/JeuRXu2UaBb

Improvements:
- Perform a search only on selectors, not a full text search. This means that you only get the Nodes that the selector affects, not the full-text-search that searching "a" or "p" would do.

Usability issues:
- What if the user already has a search performed?  I am attempting to stash their search and restore their search state when I would normally clear.

[Joseph Pecoraro]

Comments from pfeldman in IRC:

- it is more than discoverable, that is a bit annoying.
- what is the user story for this feature?
- it is rarely required to navigate from selector to a node, this should be a popup menu-level feature... you need it rarely.
- if only you highlighted them in the inspected page, i would buy it. highlighting in inspector is not useful. i mean i will see it in the mess of other tags, so what... whereas on the page it makes perfect sense
- ideally, i would like it to highlight in yellow and dim as the navigation to resource does with the line. that way it will not have the "marked" state and will be ideal!
- while editing style, we could keep the highlight until change is committed

I am not sold that it is not useful in the inspector.  I agree it would be useful to highlight them on the inspected page (would require adding support for highlighting multiple nodes in inspector clients).

[Timothy Hatcher]

The use case I see for it is to know what other elements you mgith be affectign with this style rule. So if you edit, you know what other things you are affecting.

A pop-up menu item seems fine, it would be the first one on style rules.

Maybe we don't inject the selector in the search field if it clears when you move the mouse out. Just do the search behind the scenes and highlight the nodes in the tree (and/or page). If they had a search this would temporality replace the highlighted nodes until the mouse left, then it would restore.

[Adam Barth]

Comment on attachment 41550 [details]
[PATCH] Perform Search when Single Clicking a Selector

joepeck is a committer.

[Joseph Pecoraro]

Comment on attachment 41550 [details]
[PATCH] Perform Search when Single Clicking a Selector

clearing flags on already committed patch.

[Blaze Burg]

The UI for this feature needs to be rethought.

[Timothy Hatcher]

We could show a magnifying glass next to the selector that triggers it.

[Nikita Vasilyev]

A year ago, we started to highlight DOM nodes on the web page when hovering on selectors.

Bug 145658: Web Inspector: Hovering over CSS selectors in Styles panel show highlight matching elements on the web page

In addition to that, perhaps we should highlight DOM tree outline nodes when hovering over selectors.

[Timothy Hatcher]

Nikita is right. I think we can close this at this point.