Entering RLM (or LRM) character first in a text box causes the caret and the text box to become fifth of their usual height
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | affected |
| firefox131 | --- | wontfix |
| firefox132 | --- | wontfix |
| firefox133 | --- | fix-optional |
People
(Reporter: itiel_yn8, Unassigned)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(2 files)
Found in the wild here:
https://pontoon.mozilla.org/he/firefox/all-resources/?string=311246
(need to log in and go to the same version of this string in your locale in which you have translation priviledges)
Entering an RLM or LRM will cause the attached screenshot.
Comment 1•1 year ago
|
||
Set release status flags based on info from the regressing bug 1855583
:dshin, since you are the author of the regressor, bug 1855583, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Comment 2•1 year ago
|
||
Right, the field becomes tiny because it has no height - the only thing left is border/padding.
So it uses contenteditable divs - Things seem to work slightly differently in terms of sizing, given that empty divs get the line height.
The reporter's case is indeed a regression - Previously, specifying white-space: break-spaces caused the div to get a proper line height. Additional emptiness check from bug 1855583 foils this, as we consider LTR/RTL character to be "empty."
I think that maybe we should not consider these characters as empty? Use of LTR/RTL characters seem a lot more deliberate than spaces. Also - that's how Blink and WebKit seem to behave, since they give line-height to all of the testcases, where Gecko pre-bug 1855583 still wouldn't give line height to divs that don't have white-space set.
Updated•1 year ago
|
Updated•1 year ago
|
Description
•