New issue
Advanced search Search tips

Issue 670498 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Find text not working on previously hidden elements

Reported by term...@gmail.com, Dec 2 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Steps to reproduce the problem:
1. Go to https://sourceforge.net/projects/codeblocks/files/Binaries/16.01/Windows/
2. Open the find box (CTRL+F) and paste in a721554
3. Observe no matches since that text isn't shown
4. Show the sha1 hash for codeblocks-16.01mingw-setup.exe by clicking on it's 'i' information icon 
5. Notice the find box still says 0
6. Delete the text from the find box
7. Paste in a721554 again
8. Notice the find box still says 0
9. Hit backspace to remove the last digit '4'
10. Notice the find box updates

What is the expected behavior?
The expected result is that if the user does an action that unhides an element any shown text should be considered findable text. Whether this should be automated or not I don't know but manual doesn't work either, I can't just click the carets to force a manual update because they're greyed out.

What went wrong?
Please see the attached animated GIF file which demonstrates the problem as described in the steps to reproduce.

Did this work before? N/A 

Chrome version: 54.0.2840.99  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 23.0 r0
 
find text not working.gif
80.0 KB View Download

Comment 1 by ajha@chromium.org, Dec 5 2016

Components: -UI UI>Browser>FindInPage
Labels: M-54
Labels: -Type-Bug -Pri-2 -M-54 hasbisect-per-revision M-57 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: paulmeyer@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10, Mac 10.12.1 and Ubuntu 14.04 using chrome reported version #54.0.2840.99 and latest canary #57.0.2942.0.

Bisect Information:
=====================
Good build: 53.0.2760.0	Revision(397956)
Bad Build : 53.0.2762.0	Revision(398431)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/41b2e7dad0fb637ebcf9dbd6c0e60d4bfbde48ee..1514931b7dd9bcb5706e2dfa32e3d4e64f60d887

From the above change log suspecting below change

Review url: https://codereview.chromium.org/1959183002

paulmeyer@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Comment 3 by ajha@chromium.org, Dec 14 2016

Friendly ping to get an update on this issue.
@paulmeyer -- Gentle remainder for update on this issue.
Just to update, this issue is still reproducible on Windows and Linux Stable# 55.0.2883.87 and Mac Stable# 55.0.2883.97.

Thank You.
I have a fix for this issue already, but it hit a snag in review a while back: https://codereview.chromium.org/2428613002/, and was then deprioritized when some other higher priority issues came up. I will try to get back to it soon.
Status: Fixed (was: Assigned)
This bug no longer repros for me. I have done a bunch of work on find-in-page lately, so one of my patches likely fixed this, but I'm not sure which one.

Please reopen if you get this to repro again.

Sign in to add a comment