Issue metadata
Sign in to add a comment
|
Surfaces coming from render processes must be clipped to the bounds of their owning WebContents
Reported by
aiman.an...@etouch.net,
Sep 4
|
||||||||||||||||||||
Issue descriptionChrome Version: 71.0.3542.0 (Official Build) Revision 4097c6595e73c799040bc3a99bcfcc6adb178386-refs/branch-heads/3542@{#1} (64-Bit) OS: Mac (10.12.6, 10.13.1, 10.13.6, 10.14). Test URL: https://www.google.com/intl/en-GB/gmail/about/# What steps will reproduce the problem? 1. Launch chrome, navigate to the above Test URL and open dev-tools. 2. Dock dev-tool window to bottom and navigate to Audit. 3. Click on 'Run Audits' and observe the emulated window while audit is running. Actual Result: Emulation mode window gets overlapped with bottom docked dev-tools panel on running audit. Expected Result: Emulation mode window should not overlap dev-tools window while running audit. This is a regression issue, broken in 'M-70', and below is the bisect provided using per-revision script. Good Build:70.0.3503.0 (Revision:578160) Bad Build: 70.0.3504.0 (Revision:578510) You are probably looking for a change made after 578333 (known good), but no later than 578334 (first known bad). CHANGE-LOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/bcb7db78edc13f57577f0a9562c98918bdcc10ae..67d21d10815fe6d87d1785a65a50fbc386e6605b Suspect: https://chromium.googlesource.com/chromium/src/+/67d21d10815fe6d87d1785a65a50fbc386e6605b @ellyjones: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Issue is Mac OS specific and is not reproducible on Windows(7,8,8.1,10) and Linux(14.04 LTS). Kindly refer the attached screen-cast. Thank You!
,
Sep 4
Not immediately sure why this would be a window level issue, as this isn't a type of Widget that we're giving custom levels to... are we?
,
Sep 4
Confirmed that this is not a window level issue, as we are not creating a window for the little "auditing" dialog. This can be confirmed with Quartz Debug: in the window list you will see that the browser window and everything in it is in one row, and it's assigned window level 0. This seems to be a core MacViews issue. We have two WebContentses side by side, yet the WebContents on the top is escaping its bounds to overdraw the one on the bottom. I'm sending this to ccameron as he's worked on RWHVM recently; +tapted as someone who's familiar with the inner workings of MacViews, as I'm going to be out for an extended time and won't be able to pick this up for a while.
,
Sep 4
This keeps crashing in intersection_geometry.cc when I try to repro. I'll file a bug and cross-link.
,
Sep 4
This highly-suspicious DCHECK is now filed as bug 880388 . Please keep an eye on it and dup this bug to that one if it turns out to be the same cause.
,
Sep 4
Also, ccameron, tapted: That DCHECK is in a renderer process. If a render process is able to specify crazy coordinates, and we *use them* to place an image splatting out of bounds, that's really really bad. Can we verify coordinates?
,
Sep 4
,
Sep 28
The DCHECK is unrelated. If you fiddle with scrollbar settings, you can make the DCHECK go away, but this surface issue remains.
,
Oct 1
This is probably related to embedding WebContentsView via NativeViewHost ... I'm doing some cleanup in that area presently. I think (need to verify!) that there are several paths that are only hit by tests -- it might be nice to disable everything except what gets hit in production. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by ellyjo...@chromium.org
, Sep 4Owner: a...@chromium.org