Bug 17126 - Web Inspector: selectors in the Styles pane should trigger a search for that selector when clicked
Summary: Web Inspector: selectors in the Styles pane should trigger a search for that ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2008-01-31 17:06 PST by Adam Roben (:aroben)
Modified: 2016-07-01 13:35 PDT (History)
7 users (show)

See Also:


Attachments
[PATCH] Perform Search when Single Clicking a Selector (3.06 KB, patch)
2009-10-20 23:08 PDT, Joseph Pecoraro
no flags Details | Formatted Diff | Diff
[PATCH] Perform Search when Single Clicking a Selector (4.04 KB, patch)
2009-10-20 23:25 PDT, Joseph Pecoraro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2008-01-31 17:06:57 PST
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.
Comment 1 Adam Roben (:aroben) 2008-01-31 17:12:22 PST
<rdar://problem/5718859>
Comment 2 Joseph Pecoraro 2009-10-20 23:08:37 PDT
Created attachment 41549 [details]
[PATCH] Perform Search when Single Clicking a Selector

This turns out to be really awesome!  Great job whoever implemented searching!
Comment 3 Joseph Pecoraro 2009-10-20 23:13:15 PDT
Video Showing What this feels like: (although my commentary is horrible!)
http://screencast.com/t/rFBUL7vy2d
Comment 4 Joseph Pecoraro 2009-10-20 23:25:50 PDT
Created attachment 41550 [details]
[PATCH] Perform Search when Single Clicking a Selector

Piggy backing a little fix for editing attributes at the same time.
Comment 5 Joseph Pecoraro 2009-10-21 06:45:54 PDT
Landed in http://trac.webkit.org/changeset/49904
r49904 = 0b3e4bd8da685736976258b07c4234273878c9f9
Comment 6 Pavel Feldman 2009-10-21 07:20:26 PDT
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.
Comment 7 Joseph Pecoraro 2009-10-21 08:38:30 PDT
(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.
Comment 8 Joseph Pecoraro 2009-10-23 17:20:00 PDT
> > 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.
Comment 9 Joseph Pecoraro 2009-10-23 18:03:28 PDT
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).
Comment 10 Timothy Hatcher 2009-10-23 19:59:12 PDT
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.
Comment 11 Adam Barth 2009-11-12 18:51:24 PST
Comment on attachment 41550 [details]
[PATCH] Perform Search when Single Clicking a Selector

joepeck is a committer.
Comment 12 Joseph Pecoraro 2009-11-12 19:37:53 PST
Comment on attachment 41550 [details]
[PATCH] Perform Search when Single Clicking a Selector

clearing flags on already committed patch.
Comment 13 BJ Burg 2014-01-26 18:40:51 PST
The UI for this feature needs to be rethought.
Comment 14 Timothy Hatcher 2015-01-25 07:59:10 PST
We could show a magnifying glass next to the selector that triggers it.
Comment 15 Nikita Vasilyev 2016-06-17 11:31:16 PDT
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.
Comment 16 Timothy Hatcher 2016-07-01 13:35:09 PDT
Nikita is right. I think we can close this at this point.