White patch appears momentarily after giving print command in fullscreen mode.
Reported by
vku...@etouch.net,
Oct 17 2017
|
|||||
Issue descriptionChrome Version:62.0.3202.62 (Official Build)Revision 9da914b118cb0d10d715ccc4ad20575a0305a304-refs/branch-heads/3202@{#700} (32/64-bit) OS:Win(7,8,10) What steps will reproduce the problem? (1)Launch chrome and navigate chrome://settings/ (2)Press 'F11' from keyboard to toggle in fullscreen mode (3)Give print command ctrl+p and simultaneously observe at the bottom of print window. Actual: White patch appears momentarily after giving print command in fullscreen mode. Expected: No such white patch should be seen after giving print command in fullscreen mode. This is a Non-regression issue seen from 'M45' series i.e 45.0.2404.0 Note: Issue not seen on Mac & Linux OS.
,
Oct 17 2017
Marking this as P3 and removing the milestone, given this is not a regression and a very minor bug. There may be some jank in the UI redrawing that's causing the white border on the bottom.
,
Oct 18 2017
Also, I think this happens on all platforms, it's just in release builds, it redraws fast enough on non-Windows platforms that it's hard to see.
,
Oct 18 2017
When running a debug build with --slow-down-compositing-scale-factor=1000 to make the animation obnoxiously slow, this is much more obvious. In chrome/browser/resources/print_preview/print_preview.html, I made the <body> of the print preview page red, and it appears that's the element we are seeing in this bug. For some weird reason, my Linux workstation, with 2 identical monitors, only triggers this on the left monitor that has a taskbar from the WM. Having the browser window full screen on the right monitor does not trigger this. Also, in this mode, if the browser window is not maximized and print preview is displayed, maximizing the browser window will cause the print preview dialog to display a big patch of red before the elements inside get resized to draw over the red <body> tag. danakj: Any advice on who to talk to about this bug? Is is a compositor issue? Blink painting / layout?
,
Oct 18 2017
Sounds like a layout+paint occurs where the body is larger, without the rest being resized. I'm can't say if that's a layout bug or not, it would depend on what the inputs to blink are.
,
Oct 23 2017
ikilpatrick: Can you help give some guidance here as well?
,
Oct 24
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ranjitkan@chromium.org
, Oct 17 2017