Bug 132188 – <textarea> with float:left disappears when editing text

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Björn Barnekow]

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

[Michael Catanzaro]

Nice....

I can reproduce only if I delete *all* of the text (Ctrl+A then Delete).

[Ahmad Saleem]

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!

[Michael Catanzaro]

I can't reproduce anymore. Probably fixed at some point in the past several years.

[Karl Dubost]

Created attachment 466559 [details]
screen recording on STP 171

It is vanishing on Safari Technical Preview 171

[Radar WebKit Bug Importer]

<rdar://problem/110093535>

[Michael Catanzaro]

Reopening

[Ahmad Saleem]

OK, I did try it with Ctrl+A on whole text rather than paragraph.

@Karl - thanks a lot for video.

[Ahmad Saleem]

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.

[Ahmad Saleem]

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.

[alan]

yeah, this looks like a repaint bug so that blink change may indeed be relevant. will take a look into it in a bit.

[alan]

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.

[alan]

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.

[alan]

Created attachment 466589 [details]
Patch

[Simon Fraser (smfr)]

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..."?

[alan]

Created attachment 466608 [details]
Patch

[EWS]

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].