New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 679850 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit 29 days ago
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Search in Elements tab is not working for newly added elements

Reported by ovkadu...@gmail.com, Jan 10 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
Here's a jsfiddle: https://jsfiddle.net/ovkadurin/hscwqdad/
and there's an animated gif in the attachment (elements_search.gif)

1. Go to the link above (jsfiddle) 
2. Open devtools, open Elements panel
3. Search for elements that have "css-class" 
4. Remember the number of found elements (there are 3 elements initially)
5. Click on the button "Add the new div"
6. Tack a look at the Elements panel. Notice that the new elements was added
7. Go to the search panel (we haven't close it) and try to find elements again.
AR: The number in the Search panel is the old one - 3. If finds only old elements.
ER: Show valid number of elements found, find all newly added elements.

How to work around.
Close the panel. And open it again. If finds all the elements.

What is the expected behavior?

What went wrong?
The Elements finder should find all the elements, including those which were added dynamically. It should work without closing/opening the Elements Search panel.

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

It's reproducible on "Version 55.0.2883.87 m (64-bit)" and on "Version 57.0.2977.1 canary SyzyASan".
 

Comment 1 by ovkadu...@gmail.com, Jan 10 2017

elements_search.gif
3.3 MB View Download
Labels: Needs-Triage-M55
Cc: kkaluri@chromium.org
Labels: M-57 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue in windows 10, Ubuntu 14.04 and mac 10.12.2 with chrome version M55-55.0.2883.87 and in earlier version of chrome M30-30.0.1549.0.
This is a non-regression issue and marking it as untriaged.

Attaching a screencast for your reference
Issue 679850.mp4
2.6 MB View Download

Comment 4 by alph@chromium.org, Jan 11 2017

Owner: lushnikov@chromium.org
Status: Assigned (was: Untriaged)
I've just found out that if in the step 7 finding elements using Ctrl + F5, then everything is found. But pressing the Enter key instead in the search textbox doesn't help. Even selecting the entire search phrase and then pressing the Enter doesn't help.
So it might be not obvious for developers to figure out how to trigger the new search and that the pressing the Enter is not "search" but the "show me the next item you've already found".
Maybe it makes sense to add the implicit "Search" button next to the search field?
So if you tell how it should work, I can try to fix it and then send my CL.
> 4. Remember the number of found elements (there are 3 elements initially)

I see "11" found elements after I search!

But you are right, until I re-open the search, the new one is not discovered. That is worth fixing, go for it!
> 4. Remember the number of found elements (there are 3 elements initially)
>>I see "11" found elements after I search!

The thing is that I forgot to specify that you should insert ".css-class" and not "css-class" (notice a dot before the class name).

>But you are right, until I re-open the search, the new one is not discovered. That is worth fixing, go for it!
It's not clear for me how it should work.
I can suggest different approaches:
1) Every pressing of Enter should make a new search and displays all the found items
2) Only selecting the entire search phrase and then pressing Enter should trigger new search.
3) It continue working as is. But I add the "Search" button which make a new search.
It's interesting how the "Ctrl + F" search is implemented in the Chrome itself. 
You can  check out the animated gif in the attachment.
What I did there is visited https://www.youtube.com/user/Google/videos , pressed "Ctrl + F" and typed "pixel".
Initially it found two occurrences of the search phrase. And when I pressed "Load more" the web page loaded more items. 
Then the search algorithm works as follows (the focus on the phase when the _new_ request is triggered):
* When a user clicks inside the search field (focuses it) and presses either Enter or Previous/Next arrows
** It goes from the current found item up/down to the next one, until it reaches the maximum/minimum count
** When it hits the maximum/minimum count, the _new_ request is triggered
** The number of maximum count is changed (if there were changes on the web page)
** New items are available for being iterating (if needed)

It looks pretty good. No need to make a _new_ request every time a user presses Enter or Previous/Next arrows.
The good time for requesting is when a user reaches the max/min item.

So my suggestion is to follow that algorithm. What do you think?
search_elements_in_chrome.gif
7.8 MB View Download
I think we can afford searching every time you hit enter. That would also keep code simple.
Ok. Then I would like to work on this ticket.
Please go ahead. The system won't let me assign it to you, but as long as we are aware you are doing it, it is alright!
I got it. Thanks!
Status: Fixed (was: Assigned)

Sign in to add a comment