Bug 230336

Summary: [css-writing-modes][css-flexbox] Fix for orthogonal writing modes when the parent is not the containing block
Product: WebKit Reporter: Sergio Villar Senin <svillar>
Component: New BugsAssignee: Sergio Villar Senin <svillar>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ahmad.saleem792, changseok, esprehn+autocc, ews-watchlist, glenn, kondapallykalyan, pdr, rbuis, rego, svillar, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch svillar: review?, ews-feeder: commit-queue-

Description Sergio Villar Senin 2021-09-16 02:08:47 PDT
[css-writing-modes][css-flexbox] Fix for orthogonal writing modes when the parent is not the containing block
Comment 1 Sergio Villar Senin 2021-09-16 02:17:58 PDT
Created attachment 438330 [details]
Patch
Comment 2 Rob Buis 2021-09-16 02:31:52 PDT
Comment on attachment 438330 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=438330&action=review

> Source/WebCore/ChangeLog:8
> +        Absolutelly positioned items are not properly auto positioned when its containing block is not its parent

Absolutely.

> Source/WebCore/rendering/RenderBox.cpp:4290
> +    else if (logicalTopAndBottomAreAuto && child->parent() != &containerBlock && !is<RenderView>(containerBlock) && child->parent()->style().isFlippedBlocksWritingMode())

I can't find any explanation why there needs to be a check for RenderView?
Comment 3 Sergio Villar Senin 2021-09-16 02:34:26 PDT
To give some more context. Check the following example

<style>
.abspos { position: absolute; width:10px; height:40px; background: red; }
.parent { background-color: #aaa; height: 100px; width: 100px; }
.vertical-rl { writing-mode: vertical-rl; }
</style>

<p>parent == containing block</p>
<div class="parent vertical-rl" style="position:relative">
  <div class="abspos"></div>
</div>

<p>parent != containing block</p>
<div style="position:relative">
  <div class="parent vertical-rl">
    <div class="abspos"></div>
  </div>
</div>

Both should be rendered the same, however WebKit incorrectly positions the abspos item in the second example in the top-left corner instead of the top-right.

Let's first examine why the first case works properly. In the case of containingblock == parent we have a RenderLayer for the parent (because it's position:relative) and another RenderLayer for the abspos item (because it's position absolute). Then when RenderLayer::updateLayerPosition() is called we do box->applyTopLeftLocationOffset(localPoint). That method effectively flips the localPoint because the renderer() of the RenderLayer is vertical-rl. This means that the RenderLayer of the abspos item will consider the top-right corner as the origin of coordinates and thus will properly place the abspos item.

The second case is different though. In that case we have a RenderLayer for the containing block and the parent and another RenderLayer for the abspos item. Here when box->applyTopLeftLocationOffset(localPoint) is called as part of RenderLayer::updateLayerPosition() nothing is flipped because the renderer() of the RenderLayer is a horizontal-tb element (the <div> with position:relative). This means that the RenderLayer of the abspos item will think that the origin of coordinates is the top-left corner. Note that the fact that the parent of the abspos is a vertical-rl writing mode is never considered, but it should because the item should be placed in the static position.

I've considered many different alternatives but this is the best one I could think of. I'm all ears for alternatives.
Comment 4 Sergio Villar Senin 2021-09-16 02:35:04 PDT
Alan I'm specially interested in your opinion here. I'd be awesome if you could take a look.
Comment 5 Radar WebKit Bug Importer 2021-09-23 02:09:16 PDT
<rdar://problem/83438065>
Comment 6 Ahmad Saleem 2024-07-05 12:24:22 PDT
@Alan - this is basically progressing same tests, which you jus did with: https://commits.webkit.org/280697@main

Marking this as duplicate of your bug.

*** This bug has been marked as a duplicate of bug 276240 ***