SitePerProcess policy causes css:hover in parent window when traversing iFrame
Reported by
apsche...@gmail.com,
Apr 11 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Navigate to http://jsfiddle.net/nickleaf/tKsyw/1/ (not my fiddle, just found one that shows the problem) 2. From above the youtube iframe starting at top left, move mouse down into the iframe and back up out of the iframe (see attached image) 3. Do this from left to right across the top of the iframe What is the expected behavior? No change to the top navigation of the parent (fiddle) site What went wrong? Hover effects are shown on the top navigation (underlines) when the cursor is nowhere near the top navigation. This can be especially disruptive if there are dropdown navigations based on hover effects (top menus pop down unexpectedly) Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: 10.0 Flash Version: Enabling and Disabling SitePerProcess policy will cause behavior to show or not show.
,
Apr 12 2018
Tested this issue on Debian Rodete with chrome #65.0.3325.181 Observations: Even though Site-Per-Process flag is enabled or disabled, the issue is still exists in both scenarios. Attaching the screen-cast for reference. apschenck@ Could you please look into it and confirm this issue is related to site-per-process flag. Thank You...
,
Apr 12 2018
When I go to flip the flag on Site-Per-Process I notice it is disabled. However, when I go to chrome://policy I see SitePerProcess set to True. When I set the registry key to 0 the behavior goes away. When I set it to 1 the behavior returns. Changing these keys does not change the Site-Per-Process flag you show. https://www.chromium.org/administrators/policy-list-3#SitePerProcess
,
Apr 12 2018
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
,
Apr 12 2018
This is very unlikely to be related to the enterprise policy setting per se, but rather to the out-of-process iframe functionality (however you enable it). I assume it would also affect all platforms where we have Site Isolation.
,
Apr 12 2018
Yes, this looks like a legitimate bug in Chrome 65, and I can repro it on ChromeOS 65.0.3325.209 and Windows 65.0.3325.181 with Site Isolation enabled. Thanks for the report! The bug does not repro for me on Windows 66.0.3359.66 or 67.0.3395.0, so I suspect it was fixed in M66. Ken, James, or Kevin, could you check to see which CL fixed this? A bisect (with Site Isolation enabled) would probably help.
,
Apr 12 2018
This sounds vaguely similar to issue 827229 where mouse enter/leave events are involved. It was fixed in M66, so if it does not repro there, I'm almost certain it is the root cause.
,
Apr 12 2018
Comment 7: Nice. That would be r544744 by sadrul@. We can close this if we confirm it. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by poromov@chromium.org
, Apr 12 2018Labels: Enterprise-Triaged
Owner: palmer@chromium.org