New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 747364 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Flickering of alternate shades is seen when color picker window is being scrolled up & down.

Reported by avsha...@etouch.net, Jul 21 2017

Issue description

Chrome version : 61.0.3163.0 (Official Build) ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528} 32/64 bit
OS : Windows 7,8,10), Linux(14.04 LTS)

What steps will reproduce the problem?
1. Launch chrome, open devtools on NTP and hit Ctrl + Shift + D to dock devtools to bottom.
2. In 'Styles' tab, open 'Add background-color' window and select any 'Material' color from 'Color Palettes'.
3. Now long click on any color to see alternate shades (keep shades open) and roll mouse wheel up & down.
4. Observe the alternate shades column.

Actual Result : Alternate shades column flickers when scrolling up/down in color picker window.

Expected Result : Alternate shades column should not flicker when color picker window is being scrolled up & down.

This is a regression issue broken in ‘M-61’, below is the Manual Regression range and will soon update other info.
Good build : 61.0.3154.0
Bad build : 61.0.3155.0

Note : 
1. Above issue is not reproducible in Mac(10.11.6, 10.12.3) OS.
2. Actual behaviour of issue is not captured completely in given 'Actual_Result' screencast.
 
Actual_Result.mp4
1.6 MB View Download
Expected_Result.mp4
1.4 MB View Download
Labels: hasbisect-per-revision
Owner: chrishtr@chromium.org
Status: Assigned (was: Unconfirmed)
Bisect Info:
===========
Good build : 61.0.3154.0 ,  Revision Range - 485485
Bad build  : 61.0.3155.0 ,  Revision Range - 485784

After executing the per-revision bisect script, i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/d73f07c3c79e360c3eb8e3605e24d29796b45185..b45467a31c1bd152920544cded6b571877d44846

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/b45467a31c1bd152920544cded6b571877d44846

chrishtr@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Comment 2 by chrishtr@google.com, Jul 25 2017

I can reproduce.

Comment 3 by chrishtr@google.com, Jul 25 2017

Labels: ReleaseBlock-Stable

Comment 4 by gov...@chromium.org, Jul 26 2017

URGENT - PTAL.
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the M61 branch #3163 ASAP to have enough baking time in Beta before Stable promotion. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

Project Member

Comment 5 by bugdroid1@chromium.org, Jul 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a1fa33f5f06cb27f39cf6240ca57854571f0b34e

commit a1fa33f5f06cb27f39cf6240ca57854571f0b34e
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Fri Jul 28 20:40:55 2017

Don't ever check for fragment intersections when painting ancestor clipping
masks, or clip to the compositing container.

It doesn't make sense to do this, because (a) it doesn't achieve anything,
and similar optimizations are already implemented in CompositedLayerMapping, and
(b) it is not quite correct, because the overflow clip of the stacking ancestor
is applied before checking fragment intersections, which can be wrong if the
descendant is not clipped. This latter condition caused  issue 747364 .

Bug:  749760 ,  747364 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I1485cc86c2f0dfc222171d1b53eb27f083d2c2c8
Reviewed-on: https://chromium-review.googlesource.com/589825
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490502}
[modify] https://crrev.com/a1fa33f5f06cb27f39cf6240ca57854571f0b34e/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/a1fa33f5f06cb27f39cf6240ca57854571f0b34e/third_party/WebKit/LayoutTests/compositing/overflow/relpos-under-abspos-border-radius-expected.html
[add] https://crrev.com/a1fa33f5f06cb27f39cf6240ca57854571f0b34e/third_party/WebKit/LayoutTests/compositing/overflow/relpos-under-abspos-border-radius.html
[modify] https://crrev.com/a1fa33f5f06cb27f39cf6240ca57854571f0b34e/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp

Labels: Merge-Request-61
Project Member

Comment 7 by sheriffbot@chromium.org, Jul 29 2017

Labels: -Merge-Request-61 Hotlist-Merge-Approved Merge-Approved-61
Your change meets the bar and is auto-approved for M61. Please go ahead and merge the CL to branch 3163 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 8 by gov...@chromium.org, Jul 30 2017

Pls merge you change to M61 branch 3163 before 3:00 PM PT on Monday so we can take it in for next week last M61 Dev release. Thank you.
Project Member

Comment 9 by bugdroid1@chromium.org, Jul 31 2017

Labels: -merge-approved-61 merge-merged-3163
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8f00c5f7e1a6310c063e2cb0507ce6935aa8d983

commit 8f00c5f7e1a6310c063e2cb0507ce6935aa8d983
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Mon Jul 31 21:45:54 2017

Don't ever check for fragment intersections when painting ancestor clipping masks, or clip to the compositing container.

It doesn't make sense to do this, because (a) it doesn't achieve anything,
and similar optimizations are already implemented in CompositedLayerMapping, and
(b) it is not quite correct, because the overflow clip of the stacking ancestor
is applied before checking fragment intersections, which can be wrong if the
descendant is not clipped. This latter condition caused  issue 747364 .

TBR=chrishtr@chromium.org

(cherry picked from commit a1fa33f5f06cb27f39cf6240ca57854571f0b34e)

Bug:  749760 ,  747364 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I1485cc86c2f0dfc222171d1b53eb27f083d2c2c8
Reviewed-on: https://chromium-review.googlesource.com/589825
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#490502}
Reviewed-on: https://chromium-review.googlesource.com/594662
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#187}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/8f00c5f7e1a6310c063e2cb0507ce6935aa8d983/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/8f00c5f7e1a6310c063e2cb0507ce6935aa8d983/third_party/WebKit/LayoutTests/compositing/overflow/relpos-under-abspos-border-radius-expected.html
[add] https://crrev.com/8f00c5f7e1a6310c063e2cb0507ce6935aa8d983/third_party/WebKit/LayoutTests/compositing/overflow/relpos-under-abspos-border-radius.html
[modify] https://crrev.com/8f00c5f7e1a6310c063e2cb0507ce6935aa8d983/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp

Status: Fixed (was: Assigned)

Sign in to add a comment