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

Issue 599573 link

Starred by 1 user
Status: Fixed
Owner:
wangxianzhu@chromium.org
Closed: Apr 2016
Cc:
█ trchen@chromium.org
█ le...@chromium.org
wangxianzhu@chromium.org
e...@chromium.org
chrishtr@chromium.org
█ wkorman@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Incorrect visual overflow for element with box-shadow and flipped blocks writing mode

Project Member Reported by wangxianzhu@chromium.org, Mar 31 2016 
<div id='container' style='backface-visibility: hidden; writing-mode: vertical-rl'>
    <div id='target' style='box-shadow: 40px 20px black; width: 100px; height: 50px; background-color: green'>
        ABCDE
    </div>
</div>

The right box-shadow of target is cut off because the container calculates its visual overflow incorrectly.

Comment 1 by wangxianzhu@chromium.org, Mar 31 2016

Summary: Composited layer geometry incorrect for element with flipped blocks writing mode (was: Descendant visual overflow added to container visual overflow wrongly with flipped block writing mode)
Correct composited layer geometry of container should be (8,8 140x70). Now it's (-32, 8, 140x70).

I'm totally confused by the call sites of LayoutBox::flipForWritingMode(). The above result seems a result of an unnecessary flipForWritingMode(). When should we call flipForWritingMode(), when not?

Comment 2 by wangxianzhu@chromium.org, Mar 31 2016 

This could be a problem of visual overflow calculation, not the flipForWritingMode() call in PaintLayer::physicalBoundingBox(). We add visual effect overflow in physical coordinates into visual overflow rect. It seems that we should flip visual effect overflow to block direction coordinates. Is this correct?

Comment 3 by wkorman@chromium.org, Mar 31 2016

Cc: wkorman@chromium.org
Your understanding of the right thing to do sounds correct to me, link which bit of code you're looking at?

I don't think we would add overflow in physical, believe it should be logical, and does need flipping.

There may be multiple bugs at hand, for example we still have an open bug http://crbug.com/472330 incorrect cull rect for box-shadow in vertical-rl.

Comment 4 by wangxianzhu@chromium.org, Mar 31 2016

Owner: wangxianzhu@chromium.org
Status: Assigned (was: Available)
Summary: Incorrect visual overflow for element with box-shadow and flipped blocks writing mode (was: Composited layer geometry incorrect for element with flipped blocks writing mode)

Comment 5 by wangxianzhu@chromium.org, Mar 31 2016

Cc: trchen@chromium.org wangxianzhu@chromium.org
 Issue 597965  has been merged into this issue.
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 1 2016 

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

commit ac7511d8075f109d87040a2d782b641d4b8e40c9
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Fri Apr 01 17:00:45 2016

Fix wrong box-shadow visual overflow with flipped blocks writing mode

BUG= 599573 
TEST=fast/box-shadow/shadow-box-resize-writing-mode.html
TEST=LayoutObjectTest.OverflowRectMappingWithSelfFlippedWritingMode
TEST=LayoutObjectTest.OverflowRectMappingWithContainerFlippedWritingMode

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

Cr-Commit-Position: refs/heads/master@{#384613}

[modify] https://crrev.com/ac7511d8075f109d87040a2d782b641d4b8e40c9/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/ac7511d8075f109d87040a2d782b641d4b8e40c9/third_party/WebKit/Source/core/layout/LayoutObjectTest.cpp
[modify] https://crrev.com/ac7511d8075f109d87040a2d782b641d4b8e40c9/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp

Comment 7 by wangxianzhu@chromium.org, Apr 1 2016

Status: Fixed (was: Assigned)
►

Sign in to add a comment