Created attachment 230163 [details] textarea test setup: textarea with float:left or float:right, some text, enough to scroll action: delete some text bug: <textarea> disappears completely, reappears undoing the text change
Nice.... I can reproduce only if I delete *all* of the text (Ctrl+A then Delete).
Is it platform specific because I am not able to reproduce this bug in Safari 16.5 & STP171. I think it might got fixed along the way and we can mark this as "RESOLVED CONFIGURATION CHANGED". Thanks!
I can't reproduce anymore. Probably fixed at some point in the past several years.
Created attachment 466559 [details] screen recording on STP 171 It is vanishing on Safari Technical Preview 171
<rdar://problem/110093535>
Reopening
OK, I did try it with Ctrl+A on whole text rather than paragraph. @Karl - thanks a lot for video.
Similar bug in Chrome: crbug.com/833602 Based on comment 04, it happens with non-textarea as well: https://bugs.chromium.org/p/chromium/issues/detail?id=833602#c4 Tested with the above test case (from Chrome bug) as well and it is reproducible in Safari.
CCing Alan - since Google / Blink fix was in Layout / Rendering area. We might have different bug but just wanted to get input from layout & rendering side.
yeah, this looks like a repaint bug so that blink change may indeed be relevant. will take a look into it in a bit.
Created attachment 466577 [details] (non-textarea) test reduction This bug is not specific to textarea. Floats going from self-painting to non-self-painting have this bug when they are also considered layout boundaries.
when a self-paining float becomes non-self painting, its containing block starts taking care of it painting. Containing block consults the floating object's shouldPaint() to check if it is supposed to initiate the paint of the float box (this is at paint time) shouldPaint() relies on an up-to-date value of m_paintsFloat. m_paintsFloat gets updated at _layout_ time (see RenderBlockFlow::addIntrudingFloats). However when the layout's entry point is the float (and then the float becomes non-self-painting) its containing block never gets the chance to update the m_paintsFloat bit since layout flow never reaches said containing block.
Created attachment 466589 [details] Patch
Comment on attachment 466589 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=466589&action=review > COMMIT_MESSAGE:16 > +4. However self-paining float boxes always paint themselves (this is not specific to floats, all renderers behave like this). "self-paining" > Source/WebCore/rendering/RenderBox.cpp:5722 > +void RenderBox::updateFloatBoxAfterSelfPaintingLayerChange() "update float box" makes it sound like this is changing the float box itself. Maybe "updateFloatPainter..."?
Created attachment 466608 [details] Patch
Committed 264943@main (df850bbc342e): <https://commits.webkit.org/264943@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 466608 [details].