>>> My Info: Win7_64, Nightly 48, 32bit, ID 20160323030400 STR (2 scenarios: A and B) 1.A) Open data:text/html,<pre class="paragraph">1st paragraph.<br>In this paragraph...</pre> 1.B) Open data:text/html,<pre class="paragraph">1st paragraph.%0AIn this paragraph...</pre> 2. Open devtools -> Inspector. Type "paragraph" in the field "Search HTML". 3. Press Enter 4. Press Enter 5. Press Enter AR: A) [good] After each pressing of Enter (Steps 3-5) a new element is selected in markup B) [bad] After each pressing the counter changes: "1 of 2", "2 of 2", but the same element is selected in markup. When I inspect a long HTML, it's not always clear whether I should wait some time until the next found string is selected OR the string I was searching for is also presented in inline text ER: It should be easy to distinguish text found inside the node itself and inside its inline text This was introduced by combination of bug 835896 and bug 892935. In my personal view both bugs introduced several not nice things that are hard to control

Good point, we should distinguish visually where is the string matching in the node. I believe Brian had already filed this as another bug though when he worked on the full-text search feature. Brian, can you duplicate this one if possible?

(In reply to Patrick Brosset [:pbro] from comment #1) > Good point, we should distinguish visually where is the string matching in > the node. > I believe Brian had already filed this as another bug though when he worked > on the full-text search feature. > Brian, can you duplicate this one if possible? I can't find another bug exactly for this, but Bug 1224473 is quite similar. (It's requesting for the matched string to be highlighted *and* that it should not select the node in the inspector). Maybe these two should be consolidated into one once we define desired behavior. Helen, if a user searches in the Inspector as in Comment 0 in this bug (as in 1b), I'm thinking we should have some kind of marker showing which instance of 'paragraph' is matched instead of relying just on the node being selected. Do you agree? Secondly, if we had a case like 1a in which searching for 'paragraph' toggles between two nodes, do you think that we should automatically select the matched node as we do now, or only mark the text as selected and have the user then select the node themselves if they want it to be selected? The latter is basically what Bug 1224473 is requesting AFAICT.

Let's consolidate the two bugs. As for the preferred behavior, let's only highlight the matching string, and not select the node, since the node-selection highlight drowns out any other sort of marker we could use for search results. Sublime Text does search/search results well. (Here's I'm just hitting 'Enter' over and over again to cycle through results): http://cl.ly/072b0F3X3o1f The way they've done highlighting (you can see at the end that there are two results on one line) is really clear-cut and easy to use.

In addition to comment 0: If a string is found inside inline text, it may look like the node mathes entered selector itself and vice versa. Now I believe that my description of the bug is complete. URL to reproduce this comment (search for ".data"): > data:text/html,<b class="dat">Visit https://www.datamart.com/ !!!</b>

Triaging (filter on CLIMBING SHOES).

From bug 1395109 (now a dup of this one): attachment 8902625 [details] STR: ==== Use case was having a big JSON embedded as JS in a webpage. I wanted to look up if a certain string was inside the JSON string. So I searched for that string. This was not really helpful because the search highlights the whole JSON string, but the matched part is not highlighted at all. In the end I copied the whole html code into a text editor which has search hightlight for the matches. AR: === At the moment a text search in the Inspector just highlights the whole node. I think that's good, especially when doing CSS class or identifier searches. ER: === But I think it would be good if also the matched part would be hightlighed in second highlight color. This would be best for text searches, but I guess it would also be helpful when searching for CSS selectors like classes or identifiers because sometime the nodes are just huge, or have many CSS classes on it etc. It would help the eye to orientate. See screenshot to get an idea of what I mean.

(In reply to Patrick Brosset <:pbro> from comment #8) > See screenshot to get an idea of what I mean. Well, blue on blue is surely not the best choice, but I agree that having a subhighlighting is a good thing. It just needs to get ensured that the actually matched part is standing out. Sebastian