Issue metadata
Sign in to add a comment
|
[MacViewsBrowser] Black update region is seen on browser window resizing |
||||||||||||||||||||||||
Issue descriptionChrome Version: 60.0.3072.0 (MacViews) OS: macOS 10.12 What steps will reproduce the problem? (1) Continually resize the right side of the browser window to be larger and smaller When the window becomes wider, the top chrome does not always immediately widen to fill the new space. Until it does, there's a black rect in that area.
,
Feb 8 2018
[Bulk Edit] Applying M-68 milestone per email discussion with ellyjones@. Pls change it if milestone is incorrectly applied.
,
Mar 26 2018
MacViews triage: this reproduces. Over to sdy@ for M-68.
,
Mar 27 2018
Yandex (or Whale - I forget - maybe both) just made this transparent instead. But that's not ideal. It does weird things with shadows. However, if a web page has a super-slow layout we can time out trying to get a frame from the renderer to fill in pixels anyway. MacCocoa currently paints white in that case. But the MacViews toolbar area should "never" time out - I think the synchronisation step with the webcontents is interfering. Work for Viz has started submitting ~tokens for each frame -- I think we can use that somehow.
,
Mar 27 2018
,
Mar 29 2018
** Bulk Edit ** FYI: Starting 04/13 M68 will be in canary, M68 Dev promotion will be on 04/26.
,
Apr 3 2018
Attache a diagnostic video here. The blue is where we fail to draw in time -- we give the UI 50 msec to draw -- I think we should massively increase this (there's no sense in drawing anything when we don't have UI at the right size). The cyan is the issue that sdy@ fixed in the renderer with NSDisableScreenUpdates.
,
Apr 16 2018
,
Apr 16 2018
,
Apr 25 2018
Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.
,
May 7 2018
,
May 11 2018
Any progress here?
,
May 22 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tapted@chromium.org
, Jun 8 2017Labels: Phase4