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

Issue 739735 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Find doesn't work when two browser windows are open

Reported by cja...@emolecules.com, Jul 6 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. Open two windows. 
2. Visit two URLs, each of which contains a text phrase you want to find. For example, find two web pages about "fishing". Both pages must contain the word "fishing". 
3. Type Command-F or use menu "Edit-->Find" to open the "Find" box in the first window.
4. Type the word "fishing". Hits will be highlighted on the page, and you can use the up- and down-arrows of the search box to cycle through the hits.
5. In the second window, type Command-F or "Edit-->Find" to open the search box.
6. Type "fishing". It will find and highlight the hits. Note, however, that the hits on the first page have now disappeared.
7. Go back to the first page, and click on the up- and down-arrows in the search box to re-find the word "fishing". It won't do anything.

What is the expected behavior?
I expected the search functionality of the two windows to be completely independent. Typing "fishing" in the second window should not un-highlight the results in the first window, and the first window's search functionality should work correctly no matter what I type in the second window.

What went wrong?
Even though "fishing" is still in the search box of the first window, it won't search for it. It won't do anything. You have to actually change the text (for example, erase the "g" at the end and re-type it) before you can search the page again.

Did this work before? No 

Chrome version: 59.0.3071.115  Channel: stable
OS Version: OS X 10.11.6
Flash Version: disabled
 
Components: -UI UI>Browser>FindInPage
Status: Available (was: Unconfirmed)

Comment 3 Deleted

Project Member

Comment 4 by bugdroid1@chromium.org, Jan 29 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a3a307c83a7458e64919925169c2dca0b3ca8049

commit a3a307c83a7458e64919925169c2dca0b3ca8049
Author: sangwoo.ko <sangwoo108@gmail.com>
Date: Mon Jan 29 16:42:08 2018

Update buttons' state when FindPboard is updated

When global FindPboard is updated, find result is cleared
and next/prev buttons are disabled. But this makes
users unabled to find the exact string without
editing text. So enable buttons unless the text from pboard
is empty.

Bug:  739735 
Change-Id: Iad72ae1e0a88165774fecd21fe26c3a2949c60c4
Reviewed-on: https://chromium-review.googlesource.com/888229
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532459}
[modify] https://crrev.com/a3a307c83a7458e64919925169c2dca0b3ca8049/chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.mm

Comment 5 by rsesek@chromium.org, Jan 29 2018

Status: Fixed (was: Available)
Thanks for the patch!
Verified the fix on Mac 10.12.6 Chrome version #66.0.3335.0 as per the comment# 12
Attaching screen cast for reference.
Observed "clicking on the up and down arrows in the search box got re-find the word"
Hence, the fix is working as expected.
Adding the verified labels.

Thanks!
739735.mp4
3.6 MB View Download
Cc: viswatej...@techmahindra.com
Labels: TE-Verified-M66 TE-Verified-66.0.3335.0
Project Member

Comment 8 by bugdroid1@chromium.org, Feb 28 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f7e7f4fa0e58f902ff462fe08310291967e4e77d

commit f7e7f4fa0e58f902ff462fe08310291967e4e77d
Author: sangwoo.ko <sangwoo108@gmail.com>
Date: Wed Feb 28 03:05:17 2018

Update find bar button's state properly

Find paste board can be updated by current browser or
other browsers/applications.

1. By Current Browser(When suppressPboardUpdateActions_ is true):
We shouldn't en/disable buttons because it will be updated later based
on results. Otherwise, flickering happens( bug 815105 ).

2. By Others(When suppressPboardUpdateAcitons_ is false):
We should en/disable buttons based on text length, not on result.
prepopulateText() already does this, so revert the previous
patch. Why the  bug 739735  happnend before was that we call
clearFindResultsForCurrentBrowser() after prepopulateText().
Therfore swapping their order can resolve the bug.

Bug:  815105 ,  739735 
Change-Id: I85dc12e151fb7087a3bfab1aaf2b5d8acc3ee6b1
Reviewed-on: https://chromium-review.googlesource.com/936943
Commit-Queue: SangWoo Ko <sangwoo108@gmail.com>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539684}
[modify] https://crrev.com/f7e7f4fa0e58f902ff462fe08310291967e4e77d/chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.mm

Labels: TE-Verified-66.0.3358.0
Verified the fix on Mac 10.13.1 Chrome version #66.0.3358.0 as per the comment#0
Attaching screen cast for reference.
Observed "clicking on the up and down arrows in the search box got the searched word highlighted, with out removing any character"
Hence, the fix is working as expected.
Adding the verified labels.

Thanks!
739735.mp4
4.3 MB View Download

Sign in to add a comment