New issue
Advanced search Search tips

Issue 889639 link

Starred by 2 users
Status: Assigned
Owner:
sdy@chromium.org
Cc:
a...@chromium.org
viswa.karala@chromium.org
tapted@chromium.org
kkaluri@chromium.org
lgrey@chromium.org
phanindra.mandapaka@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Clicking find box does not cause focus to transition from url bar to other window

Reported by papod...@gmail.com, Sep 26 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce the problem:
1. Open two windows
2. Open cmd-f find box on one window
3. Select url bar in other window
4. Click cmd-f box on first window
5. Type
 demo: https://i.imgur.com/INifS9g.gifv

What is the expected behavior?

What went wrong?
Keyboard input is directed to the wrong input box, no matter how many times you click on the cmd-f find box.

Did this work before? N/A 

Chrome version: 69.0.3497.100  Channel: stable
OS Version: OS X 10.13.6
Flash Version:

Comment 1 by viswa.karala@chromium.org, Sep 27

Labels: Needs-Triage-M69

Comment 2 by phanindra.mandapaka@chromium.org, Oct 1

Cc: phanindra.mandapaka@chromium.org
Labels: Needs-Feedback Triaged-ET
papodaca@ Thanks for the issue...

Unable to reproduce the issue on reported chrome version 69.0.3497.100 using Mac 10.13.6. Attaching screen-cast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Opened two windows > opened search box by clicking cmd + f and Clicked on omnibox on another windows
3. Entered text as per screencast provided in the comment #0
As we are observed that Keyboard input is directed to the search box on 1st window

@Reporter:Could you please check the attached screen cast and please let us know if anything missed from our end and retry this issue with New profile and let us know if issue still persists.

Thanks.!
889639.mp4
3.1 MB View Download

Comment 3 by papod...@gmail.com, Oct 1 

I have since upgraded to MacOS 10.14.0, but this bug is still happening for me.
One thing I noticed, your screen cast its not running on the new "material" theme, that might be what makes the difference.
screen_cast_10.01.2018.mp4
336 KB View Download
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 1

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by ellyjo...@chromium.org, Oct 19

Labels: Needs-TestConfirmation
#2: Please re-test using the new Material UI - much of this code has changed.

Comment 6 by phanindra.mandapaka@chromium.org, Oct 22

Labels: -Needs-TestConfirmation Target-72 M-72 FoundIn-71 FoundIn-70 FoundIn-72
Status: Untriaged (was: Unconfirmed)
As per comment #3 and comment #5, Able to reproduce the issue on reported chrome version 69.0.3497.100 and latest chrome 72.0.3586.0 using Mac 10.13.6.  

Same behavior is seen on M-69 hence considering it as non-regression and marking it as Untriaged. Issue seen on Mac and Removing Needs-TestConfirmation label to it.

Note:Issue seen from from M-69 (Material UI flag is default from M-69).

Thanks!

Comment 7 by a...@chromium.org, Oct 26

Cc: tapted@chromium.org a...@chromium.org sdy@chromium.org lgrey@chromium.org
Owner: ellyjo...@chromium.org
Status: Assigned (was: Untriaged)
Clearly MacViews.

Something is seriously wrong with event targeting.

Comment 8 by ellyjo...@chromium.org, Oct 29

Cc: -sdy@chromium.org
Owner: sdy@chromium.org
Mac triage: to sdy@ for M72.

Comment 9 by viswa.karala@chromium.org, Nov 15

Cc: viswa.karala@chromium.org
 Issue 905403  has been merged into this issue.

Comment 10 by kkaluri@chromium.org, Nov 15

Cc: kkaluri@chromium.org
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
** Mass UI Triage **

Able to reproduce the issue on Mac with chrome #72.0.3610.0
►

Sign in to add a comment