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.
Comment 1 by abodenha@chromium.org
, Mar 21 2017