Bug 17126 - Selectors in the Styles pane should trigger a search for that selector when clicked
: Selectors in the Styles pane should trigger a search for that selector when c...
Status: REOPENED
: WebKit
Web Inspector
: 528+ (Nightly build)
: All All
: P2 Enhancement
Assigned To:
:
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2008-01-31 17:06 PST by
Modified: 2014-03-28 14:05 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 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 From 2008-01-31 17:12:22 PST -------
<rdar://problem/5718859>
------- Comment #2 From 2009-10-20 23:08:37 PST -------
Created an attachment (id=41549) [details]
[PATCH] Perform Search when Single Clicking a Selector

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

Piggy backing a little fix for editing attributes at the same time.
------- Comment #5 From 2009-10-21 06:45:54 PST -------
Landed in http://trac.webkit.org/changeset/49904
r49904 = 0b3e4bd8da685736976258b07c4234273878c9f9
------- Comment #6 From 2009-10-21 07:20:26 PST -------
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 From 2009-10-21 08:38:30 PST -------
(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 From 2009-10-23 17:20:00 PST -------
> > 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 From 2009-10-23 18:03:28 PST -------
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 From 2009-10-23 19:59:12 PST -------
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 From 2009-11-12 18:51:24 PST -------
(From update of attachment 41550 [details])
joepeck is a committer.
------- Comment #12 From 2009-11-12 19:37:53 PST -------
(From update of attachment 41550 [details])
clearing flags on already committed patch.
------- Comment #13 From 2014-01-26 18:40:51 PST -------
The UI for this feature needs to be rethought.