Bug 236694

Summary: [css-grid] Simplify RTL handling
Product: WebKit Reporter: Matt Woodrow <mattwoodrow>
Component: CSSAssignee: Matt Woodrow <mattwoodrow>
Status: RESOLVED FIXED    
Severity: Normal CC: changseok, clopez, dino, esprehn+autocc, ews-watchlist, glenn, jean-yves.avenard, jfernandez, kondapallykalyan, obrufau, pdr, rego, svillar, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 236626    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
none
Patch for EWS including bug 236626
none
Patch none

Description Matt Woodrow 2022-02-16 00:46:16 PST 
We currently store columns in logical order (column 0 is the rightmost physical column), but we offset these positions using the physical left border, padding and content distribution offset.

This makes for some tricky conversions to get into the final coordinates to set on the RenderElement.

I think we can store purely logical coordinates, and subtract that from the width to get the final coordinates.
Comment 1 Matt Woodrow 2022-02-16 00:50:20 PST 
Created attachment 452156 [details]
Patch
Comment 2 Manuel Rego Casasnovas 2022-02-16 05:09:40 PST 
Comment on attachment 452156 [details]
Patch

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

This is a great cleanup, if all tests keep passing (EWS are red now as the patch doesn't apply), it'd be nice to get it landed.

> Source/WebCore/rendering/RenderGrid.cpp:1575
> +LayoutUnit RenderGrid::resolveAutoStartGridPosition(GridTrackSizingDirection) const

This method doesn't use the param, please remove it.

Also this method just returns zero, do we need a method for this?

> Source/WebCore/rendering/RenderGrid.cpp:1584
>      return clientLogicalWidth();

This method is now very simple, maybe we don't need it like resolveAutoStartGridPosition().

> Source/WebCore/rendering/RenderGrid.cpp:1651
> +

Nit: Extra line not needed.
Comment 3 Matt Woodrow 2022-02-16 11:39:12 PST 
Created attachment 452219 [details]
Patch
Comment 4 Matt Woodrow 2022-02-16 11:40:30 PST 
Created attachment 452220 [details]
Patch for EWS including bug 236626
Comment 5 Matt Woodrow 2022-02-16 11:42:24 PST 
(In reply to Manuel Rego Casasnovas from comment #2)
> Comment on attachment 452156 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=452156&action=review
> 
> This is a great cleanup, if all tests keep passing (EWS are red now as the
> patch doesn't apply), it'd be nice to get it landed.

Hopefully the 'Patch for EWS' is green now, it depends on bug 236626 (which is a bit ugly, but adds a test, and inspired this cleanup).
Comment 6 EWS Watchlist 2022-02-16 11:44:18 PST 
This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess
Comment 7 Dean Jackson 2022-02-17 08:08:00 PST 
Comment on attachment 452219 [details]
Patch

rs=me but it seems iOS isn't quite happy applying the landing patch.
Comment 8 Matt Woodrow 2022-02-21 13:31:20 PST 
Created attachment 452765 [details]
Patch
Comment 9 Dean Jackson 2022-02-21 17:10:26 PST 
Comment on attachment 452765 [details]
Patch

Assuming the bots get another crack at this after the WebGPU breakage is cleared...
Comment 10 Radar WebKit Bug Importer 2022-02-23 00:47:19 PST 
<rdar://problem/89342456>
Comment 11 EWS 2022-02-24 15:19:14 PST 
mattwoodrow@apple.com does not have committer permissions according to https://raw.githubusercontent.com/WebKit/WebKit/main/metadata/contributors.json.

Rejecting attachment 452765 [details] from commit queue.
Comment 12 EWS 2022-02-24 19:11:54 PST 
Committed r290491 (247781@main): <https://commits.webkit.org/247781@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 452765 [details].