Issue metadata
Sign in to add a comment
|
Regression: Page gets stuck while capturing full size screen-shot in Dev-tools.
Reported by
aiman.an...@etouch.net,
May 31 2018
|
||||||||||||||||||||
Issue descriptionChrome Version: 69.0.3446.0 (Official Build) Revision 9850f1f2cffb7b4e0b4ea26fd6fb94048a911cd5-refs/branch-heads/3446@{#1} (32/64 Bit) OS: Mac(10.12.6, 10.13.1, 10.13.5). Pre-Condiiton: Enable 'Use Views browser windows instead of Cocoa' flag from chrome://flags and relaunch the browser. Steps to reproduce: 1. Launch chrome, navigate to NTP and open dev-tools. 2. Toggle window to Emulation Mode. 3. Click on more options icon and select 'Capture full size screen-shot' 4. Observe Actual Result: Page gets stuck while capturing full size screen-shot. Expected Result: Page should not get stuck while capturing screen-shot. This is a regression issue, broken in 'M-69', and below is the bisect provided using per-revision script. Good Build:69.0.3445.0 (Revision: 562691) Bad Build: 69.0.3446.0 (Revision: 563011) You are probably looking for a change made after 563007 (known good), but no later than 563008 (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/1e665d5f61e0558ef0b3dfe5029152f237ad9618..6be8acd7b09a2378d8c47ca9fa91b9fd9b4839ba Suspect: https://chromium.googlesource.com/chromium/src/+/6be8acd7b09a2378d8c47ca9fa91b9fd9b4839ba Christopher Cameron@: 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 not reproducible on Windows(7,8,8.1,10) and Linux(14.04 LTS) Thank You!
,
May 31 2018
Thanks for the bug report -- taking a look!
,
Jun 7 2018
This was broken before my patch, now it's broken in a new and different way with my patch. I believe that this is a DevTools issue. In the "Expected Result.mov" video, notice that at 0:17, the content is still sized wrong, and cut off (you only see half of the G from Google). This is because DevTools is calling RenderWidgetHostViewMac::SetSize with a new size, but is never re-setting it back to the original size. From the RWHVMac, I see: - SetSize: 980x8192 - SetSize: 1960x16384 - SetSize: 980x8192 and that's it. Nothing to ever set it back to its original value. The difference is that before my patch we clipped the RWHVMac (perhaps inappropriately) and with my patch, we don't clip it anymore. The original size was something more like 565x788. If we aren't told to restore it, then we won't.
,
Jun 7 2018
Of the 3 SetSize calls - the 1st is from EmulationHandler::SetDeviceMetricsOverride - the 2nd is from PageHandler::CaptureScreenshot - the 3rd is from PageHandler::ScreenshotCaptured, un-doing the 2nd one ... but it leaves things at how they were for the 1st call, which is wrong. Sending over to pfeldman to address the incorrect sizing issue. The current user workaround is to re-size the window, and everything will re-lay-out, but that is not ideal. Feel free to send back to me if macOS is doing something wrong here (in which case I'll probably want to look at it side-by-side in MTV when we get a chance).
,
Sep 19
,
Sep 19
Andrey was looking into fixing this. IIRC, it involves a race condition which messes up our "restore size" logic. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by rbasuvula@chromium.org
, May 31 2018