Issue metadata
Sign in to add a comment
|
Regression : In Fullscreen mode, black patches are seen on Print Preview page.
Reported by
yfulgaon...@etouch.net,
Mar 17 2016
|
||||||||||||||||||||||
Issue descriptionChrome version : 51.0.2681.0 2668bea689fd4a5ce07011903bca095aaf67bb07-refs/heads/master@{#381614} 32/64 bit OS : Windows 7(Win 7 aero enabled) Preconditions : In print preview, please make sure that any one of the following Destination is selected : 1. Microsoft XPS document writer 2. Fax 3. Send to OneNote 2013 4. HP Universal Printing PCL 6 Steps : 1. Launch Chrome, go to chrome://settings and press F11 to switch to full screen mode. 2. Press Ctrl P and click on 'Print using system dialog' link. 3. Now in Print dialog window, click on Cancel button and observe. Actual : After clicking on 'Cancel' button, the black patches are seen in Print Preview page. Expected : No such black patches should be seen after clicking on Cancel button. This is a regression issue broken in 'M-50' and below is the manual regression and narrow bisect info. Good build : 50.0.2657.0 Bad build : 50.0.2658.0 Narrow Bisect : https://chromium.googlesource.com/chromium/src/+log/9aab13ccc6998c63acef84a523c29b40f38ef343..b8812fef3cb23bbb30ccfd2884aba1ee60681346 Suspecting : r 377102 or 377084 from Narrow Bisect @krb : Could you please help to reassign if your change is not the cause for this issue Note : This is Windows 7 specific issue and not reproducible on Mac/Linux OS.
,
Mar 17 2016
No chance it was my change, which was strictly in the mouse input method. ananta's change is the only Windows GUI change (that I can see.)
,
Mar 18 2016
ananta@, could you please look into this change (https://chromium.googlesource.com/chromium/src/+/ed6530c9ab6cd4a56ffd70612be526dbc7db1552) if possible? Thank you!
,
Mar 19 2016
,
Mar 21 2016
Rechecked this on chrome Version 51.0.2686.0 on Windows 7. No black patches are seen after cancelling the system print dialog Window. Looks like issue is fixed.
,
Mar 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9f060d4be347cda7aa7c0fb2a43afafbbd64e70c commit 9f060d4be347cda7aa7c0fb2a43afafbbd64e70c Author: ananta <ananta@chromium.org> Date: Mon Mar 21 23:13:21 2016 Fix a painting bug which occurred due to the change which reduces the size of the fullscreen chrome window by 1 px on activation loss. We reduce the size of fullscreen windows by 1px to ensure that maximized windows on the same thread don't draw over the taskbar. This change caused a painting problem as the compositor was not aware of the changed size. This causes the compositor to not paint correctly when the fullscreen window is activated as the window size did not change. Setting the compositor size correctly to the window bounds size fixes this problem. The other bug I found was when the fullscreen window is activated, we inform the delegate about the changed client size which in turn makes it across to the webcontents. We don't want the webcontents to get notified about these size changes. Fixed by setting the flag background_fullscreen_hack_ to false after the SetBoundsInternal call. BUG= 595666 Review URL: https://codereview.chromium.org/1819633002 Cr-Commit-Position: refs/heads/master@{#382429} [modify] https://crrev.com/9f060d4be347cda7aa7c0fb2a43afafbbd64e70c/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/9f060d4be347cda7aa7c0fb2a43afafbbd64e70c/ui/views/win/hwnd_message_handler.cc
,
Mar 22 2016
Restested the above issue on Windows 7 with chrome version 51.0.2687.0 and working as intended and no black patch seen after system print is cancel. Hence marking the same as TE-Verified-51.0.2687.0. Attach is the screen-cast for the same.
,
Mar 22 2016
,
Mar 22 2016
Your change meets the bar and is auto-approved for M50 (branch: 2661)
,
Mar 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eb3477b1f3603bcc6eede00f1ce76370f3534c56 commit eb3477b1f3603bcc6eede00f1ce76370f3534c56 Author: Anantanarayanan Iyengar <ananta@chromium.org> Date: Wed Mar 23 00:42:22 2016 Fix a painting bug which occurred due to the change which reduces the size of the fullscreen chrome window by 1 px on activation loss. Merging to M50 We reduce the size of fullscreen windows by 1px to ensure that maximized windows on the same thread don't draw over the taskbar. This change caused a painting problem as the compositor was not aware of the changed size. This causes the compositor to not paint correctly when the fullscreen window is activated as the window size did not change. Setting the compositor size correctly to the window bounds size fixes this problem. The other bug I found was when the fullscreen window is activated, we inform the delegate about the changed client size which in turn makes it across to the webcontents. We don't want the webcontents to get notified about these size changes. Fixed by setting the flag background_fullscreen_hack_ to false after the SetBoundsInternal call. BUG= 595666 TBR=sky Review URL: https://codereview.chromium.org/1819633002 Cr-Commit-Position: refs/heads/master@{#382429} (cherry picked from commit 9f060d4be347cda7aa7c0fb2a43afafbbd64e70c) Conflicts: ui/views/win/hwnd_message_handler.cc Review URL: https://codereview.chromium.org/1826703002 . Cr-Commit-Position: refs/branch-heads/2661@{#353} Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081} [modify] https://crrev.com/eb3477b1f3603bcc6eede00f1ce76370f3534c56/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/eb3477b1f3603bcc6eede00f1ce76370f3534c56/ui/views/win/hwnd_message_handler.cc
,
Mar 30 2016
Verified the issue on Windows 7 using chrome latest Beta M50-50.0.2661.57 by following steps mentioned in the original comment. Observed no black patches after clicking on cancel button in the print preview page. Hence adding TE-Verified label. Thanks!
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Mar 17 2016