New issue
Advanced search Search tips

Issue 701780 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Clicking in visible rear windows to raise them also passes content clicks

Project Member Reported by dierks@google.com, Mar 15 2017

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 9000.91.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.110 Safari/537.36
Platform: 9000.91.0 (Official Build) stable-channel chell

Steps to reproduce the problem:
1. Open a window ["window A"] with a lot of active click targets covering much of the page (Gmail will do). Have it not in full-screen.
2. Open another window ["window B"] which is also not expanded to full-screen, but which obscures most of window A.
3. Click on the window A, intending to bring it to front. But happen to click in some active part of the window.

What is the expected behavior?
Window A should raise to front without changing app state. Clicks should only be passed to the app/page when the window is already frontmost.

What went wrong?
Clicking on window A passes the click through to the window, changing app state. On target-packed windows where clicks navigate the UI materially, this can be a giant pain. It's bad enough if window A is a doc/editor, and switching back and forth between editing and reviewing other sources causes the insertion point to move every time.

Did this work before? N/A 

Chrome version: 56.0.2924.110  Channel: stable
OS Version: 9000.91.0
Flash Version: 24.0.0.221 /opt/google/chrome/pepper/libpepflashplayer.so

Mac does not pass these clicks. I managed to find a Windows machine and it appears that Windows does, but I think it's broken too.
 
Status: WontFix (was: Unconfirmed)
This was a conscious decision in the UI design.

Sign in to add a comment