1721262 - text is clipped or missing in textfield input, after dynamic reflow with multi-column

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Lucas Werkmeister]

Attachment: index.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

1. Open the attached index.html.
2. Drag the link at the beginning into the first input (move mouse to link, press mouse button, move mouse to input, release mouse button).
3. Move focus to second input (with tab or by clicking into it).
4. Start typing.

Actual results:

The cursor is invisible, and, after typing, no text is visible (though the placeholder disappears).

Expected results:

The cursor and text input should be visible.

This was originally reported to me at https://github.com/lucaswerkmeister/tool-lexeme-forms/issues/74 as a bug in a website of mine (reproduced there with Firefox 88.0 on Windows and Firefox 90.0 on Windows); I subsequently reduced the HTML to the attached example (also hosted at https://github.com/lucaswerkmeister/repro-firefox-invisible-input; CC0). According to the original report, the invisible input was still sent when submitting the form (though in the reduced file I’ve removed the surrounding form).

Incomplete list of changes that all make the bug disappear:

1. Changing the style from border to outline.
2. Removing the column-count style.
3. Removing either or both of the <dt> elements.
4. Removing either or both of the <dd> elements (i.e. have the <input>s as direct children of the <dd>’s parents).

The bug also happens when dragging into the second input (and is in fact more obvious in that case, as you’d expect to see the URL you just dragged to show up). You can also replace the <dd> with a <div>, or remove the dragend listener, and the bug will persist, but I thought it would be more useful to keep those in the example: <dt> or <dd> without a surrounding <dl> is weird, and without the dragend handler the result looks more confusing, in my opinion.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for the bug report!

It looks like this is a regression -- I got a regression range using mozregression:

INFO: Last good revision: fb2b08c6bc8c320127586fcedb2626e496bf3dcf (2020-07-07)
INFO: First bad revision: ee89deeb4fb6d12456c551c5ab4aaae151ceedae (2020-07-08)
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb2b08c6bc8c320127586fcedb2626e496bf3dcf&tochange=ee89deeb4fb6d12456c551c5ab4aaae151ceedae

It's not immediately clear to me which commits in that range are likely to be related, though.

Comment 3

[Daniel Holbert [:dholbert]]

Aha, feels likely to be related to (probably regression from) bug 1645773:

Bug 1645773 - Make sure to reflow when author specified borders / backgrounds are changed if we're themed. r=jfkthame
https://hg.mozilla.org/mozilla-central/rev/2c022fc5b638633885787aa94f1e46a7e6713956

(In the attached testcase, the form fields are themed, and they change to unthemed when the drag option starts.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced, no interaction required)

Here's a more-reduced testcase.

STR:
Load the testcase and wait a second.
(If you had it open previously, use shift+ctrl+r -- the shift is necessary/helpful to reset form state, which is necessary in case you happened to have typed something longer in the relevant textbox here.)

EXPECTED RESULTS:
You should end up seeing the full text "Am I clipped?"

ACTUAL RESULTS:
Only a little bit of the letter "A" shows up. The contents of the autofocused textbox (the second one) are clipped to its original paint width (in this case the width that the initial "." value occupied).

If you change the width of your browser window, then the bug goes away. So it seems we're insufficiently reflowing in response to the form-widget theming change.

Comment 5

[Daniel Holbert [:dholbert]]

emilio, seems like this would be a good one for you to look at if you have cycles, given your formcontrol/theming work recently (and given that you were working on the regressing bug). I or someone else could take a look here too, though.

Comment 6

[Daniel Holbert [:dholbert]]

(updating/clarifying bug summary. Note that the dt/dd elements didn't end up being necessary in my reduced testcase, aside from having some display:block wrappers and/or linebreaks in particular places.)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

This particular case was broken by my patch, but it seems to happen just because of the dynamic reflow. Test-case incoming that also reproduces without the native inputs.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case 3 (no native appearance involved)

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case 3 (no native appearance involved)

With prefixed appearance for improved bisection. The regression range I get with this test-case is:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5f0961efaa1c01e5b4bc449ee5d58260393291ef&tochange=32d7797bd8bd91e7b62ef2a5e19b8888881766f1

Alice, I think you have cached builds for this range, is there any chance you could bisect this using those? If not, or if you're busy, that's totally fine of course! Just ni? me back and I'll try to manually bisect between those commits or something, because there's various things there that could be the culprit.

Thanks!

Comment 10

[Alice0775 White]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

Created attachment 9234632 [details]
Test-case 3 (no native appearance involved)

With prefixed appearance for improved bisection. The regression range I get with this test-case is:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5f0961efaa1c01e5b4bc449ee5d58260393291ef&tochange=32d7797bd8bd91e7b62ef2a5e19b8888881766f1

Alice, I think you have cached builds for this range, is there any chance you could bisect this using those? If not, or if you're busy, that's totally fine of course! Just ni? me back and I'll try to manually bisect between those commits or something, because there's various things there that could be the culprit.

Thanks!

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a632277d67072fa1312b57805d887121056002ab&tochange=8ad5fbc5b9358fc84aa43d9a1b19c851056b1f39

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Thank you!

Comment 12

[Emilio Cobos Álvarez (:emilio)]

I can try to poke a bit, we'll see.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

So I think this is a multicol / block reflow bug.

The issue is that we mark the second input as dirty when it gets the reflow request. During multicol reflow everything seems to go smoothly, but we hit this code and bail out, leaving the line marked as not dirty, and as such the stuff inside the page-break-inside: avoid dirty.

When it changes further, we think it's already dirty so don't bother adding it to the dirty root list anymore and the text frame remains with its original tiny width.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1721262 - Make sure to reflow the line again if we bail out of reflow due to break-inside: avoid. r=TYLin,dholbert

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/981cd4e1f9b2
Make sure to reflow the line again if we bail out of reflow due to break-inside: avoid. r=dholbert

Comment 16

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/29918 for changes under testing/web-platform/tests

Comment 17

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/981cd4e1f9b2

Comment 18

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot