NEW70762
Incorrect repaint during layout in flipped writing modes 
https://bugs.webkit.org/show_bug.cgi?id=70762
Summary Incorrect repaint during layout in flipped writing modes
mitz
Reported 2011-10-24 14:32:24 PDT
Created attachment 112248 [details] Test case In the test case, edit either line and notice that it does not repaint correctly. The reason is that RenderBox::computeRectForRepaint() calls flipForWritingMode() during layout, when the block’s height is still 0.
Attachments
Test case (141 bytes, text/html)
2011-10-24 14:32 PDT, mitz 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Ahmad Saleem
Comment 1 2023-03-18 06:26:43 PDT
I am able to reproduce this bug in Safari Technology Preview 165 using attached test case and Safari show 'ipsum.Lorem' in two lines with newlines in between and at top. While Chrome Canary 113 and Firefox Nightly 113 match each other. Thanks!
alan
Comment 2 2023-03-18 09:06:28 PDT
This is about horizontal-bt writing mode. Neither FF nor Chrome support this (non-standard) mode.
alan
Comment 3 2024-09-13 11:54:59 PDT
While the test case has horizontal-bt, as the title says this is about flipped writing modes in block direction mostly impacting vertical-rl.
alan
Comment 4 2024-09-13 12:10:55 PDT
The issue here is with flipped block direction an inflow child's final position (in absolute repaint coords) is unknown until its containing block finished sizing (unless containing block is the paint container). Our current repaint-after-layout logic runs descendants-first which is too early for such flipped writing modes. In many cases though this is covered up by repaints issued _before_ layout initiated by style or content change.
mitz
Comment 6 2025-09-08 09:38:35 PDT
Just for clarity, the workaround is specifically for some form controls rather than all possible manifestations of this issue, right?
Note You need to log in before you can comment on or make changes to this bug.