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

Issue 666267 link

Starred by 3 users
Status: Fixed
Owner:
wangxianzhu@chromium.org
Closed: Nov 2016
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
█ msrchandra@chromium.org
vmp...@chromium.org
dpa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Tab list disappears after clicking on 'Chrome Image' icon when browser is in RTL.

Reported by dmascare...@etouch.net, Nov 17 2016 
Chrome Version:56.0.2922.0 (Official Build) 4793d9335b9ce611e2deb40863793fa785773200-refs/heads/master@{#432511} (32/64-bit)
OS: Windows (7,8,10), Mac (10.11.6, 10.12.1), Linux (14.04 LTS)
 
Pre-condition: Select 'Right to Left' option for 'Force UI direction' flag in chrome://flags.

What steps will reproduce the problem?
1. Launch chrome and navigate to chrome://help/
2. Click on Chrome Image icon to spin the icon and observe Tab list.

Actual:Tab list disappears while icon is spinning 
Expected: Tab list should not disappear.

This is regression issue, broken in 'M 56' and below is manual info:
Good build:56.0.2909.0
Bad build:56.0.2910.0
Actual_icon.mp4
183 KB View Download
Exp_icon.mp4
215 KB View Download

Comment 1 by msrchandra@chromium.org, Nov 17 2016

Labels: hasbisect-per-revision
Owner: wangxianzhu@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build: 56.0.2909.0 (Revision: 429737).
Bad build: 56.0.2910.0 (Revision: 430103).

You are probably looking for a change made after 430094 (known good), but no later than 430095 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/59bdfe8c171d957984104767996d2e6b26594121..31922c6cd1181c77ae039adf22243cae6ca526f3

@wangxianzhu -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Thank You.

Comment 2 by msrchandra@chromium.org, Nov 17 2016

Labels: ReleaseBlock-Stable
Adding RB label as this is a recent Regression. Please remove if not required.
Thank You.

Comment 3 by rbasuvula@chromium.org, Nov 23 2016

Cc: rbasuvula@chromium.org
Still able to reproduce the issue on Ubuntu 14.04,Win 10.0 & Mac 10.11.6 using latest chrome version 57.0.2926.0.

wangxianzhu@ Could you please look into this issue.

Thanks!

Comment 4 by wangxianzhu@chromium.org, Nov 23 2016 

Will fix this before the next beta release.

Comment 5 by wangxianzhu@chromium.org, Nov 28 2016

Components: Blink>Paint>Invalidation
Reduced test case
about.html
392 bytes View Download
Project Member

Comment 6 by bugdroid1@chromium.org, Nov 29 2016 

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

commit b4a81bdbf064377ffee45f75b8ee79eb260d9942
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Tue Nov 29 04:40:19 2016

Invalidate previousLocationInBacking in LayoutObject::clearPreviousVisualRects()

clearPreviousVisualRects() is called when the object's previous visual
rects become invalid (e.g. when the object becomes composited). We
should call setMayNeedPaintInvalidationSubtree to ensure paint
invalidation checking of subtree which would be triggered by changed
location if we had valid previous location.

BUG= 666267 
TEST=paint/invalidation/compositing/become-composited-zero-offset.html

Review-Url: https://codereview.chromium.org/2537653002
Cr-Commit-Position: refs/heads/master@{#434894}

[add] https://crrev.com/b4a81bdbf064377ffee45f75b8ee79eb260d9942/third_party/WebKit/LayoutTests/paint/invalidation/compositing/become-composited-zero-offset-expected.html
[add] https://crrev.com/b4a81bdbf064377ffee45f75b8ee79eb260d9942/third_party/WebKit/LayoutTests/paint/invalidation/compositing/become-composited-zero-offset.html
[modify] https://crrev.com/b4a81bdbf064377ffee45f75b8ee79eb260d9942/third_party/WebKit/Source/core/layout/LayoutObject.cpp

Comment 7 by wangxianzhu@chromium.org, Nov 29 2016

Labels: Merge-Request-56

Comment 8 by dimu@chromium.org, Nov 30 2016

Labels: -Merge-Request-56 Merge-Approved-56 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M56 (branch: 2924)

Comment 9 by wangxianzhu@chromium.org, Nov 30 2016

Status: Fixed (was: Assigned)
Project Member

Comment 10 by bugdroid1@chromium.org, Nov 30 2016

Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/61f6db82aad91f121094b675815b5653de8ae919

commit 61f6db82aad91f121094b675815b5653de8ae919
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Wed Nov 30 04:55:51 2016

Invalidate previousLocationInBacking in LayoutObject::clearPreviousVisualRects()

clearPreviousVisualRects() is called when the object's previous visual
rects become invalid (e.g. when the object becomes composited). We
should call setMayNeedPaintInvalidationSubtree to ensure paint
invalidation checking of subtree which would be triggered by changed
location if we had valid previous location.

BUG= 666267 
TEST=paint/invalidation/compositing/become-composited-zero-offset.html

Review URL: https://codereview.chromium.org/2541763002 .

Review-Url: https://codereview.chromium.org/2537653002
Cr-Original-Commit-Position: refs/heads/master@{#434894}
Cr-Commit-Position: refs/branch-heads/2924@{#184}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[add] https://crrev.com/61f6db82aad91f121094b675815b5653de8ae919/third_party/WebKit/LayoutTests/paint/invalidation/compositing/become-composited-zero-offset-expected.html
[add] https://crrev.com/61f6db82aad91f121094b675815b5653de8ae919/third_party/WebKit/LayoutTests/paint/invalidation/compositing/become-composited-zero-offset.html
[modify] https://crrev.com/61f6db82aad91f121094b675815b5653de8ae919/third_party/WebKit/Source/core/layout/LayoutObject.cpp
►

Sign in to add a comment