Caret is hidden by spinner when text-align:right
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: 6k64x4ma, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(7 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
Open data:text/html,<input type="number" autofocus style="text-align:right">
Actual results:
The caret is hidden by the spinner
Expected results:
The caret should be visible
Comment 1•3 years ago
|
||
Regression range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=052b086a834cd4d6722d6768d8f63b4785c140f2&tochange=a2e246a3805c2021f4eb2ebf0c5e634029d5976f
--> bug 1707070
Before that, we probably just painted the piece with the caret in the foreground, which meant it remained visible, despite (apparently) barely-colliding with the spin up/down buttons.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
•
|
||
Here's a screencast showing Nightly 2021-04-25, where the cursor remains visible. I captured this screencast with Ubuntu accessibility "zoom" feature enabled, so all the pixels are scaled up.
If you look closely, you can see that indeed the cursor is overlapping the spin buttons here (the buttons' leftmost column of pixels). So it makes sense that bug 1707070's change to the paint ordering would have caused the cursor to become invisible.
Comment 3•3 years ago
|
||
For convenience, here's the reporter's data-URI testcase, as an attachment.
Comment 4•3 years ago
|
||
Here's a frame dump of testcase 1, in a local debug build of recent mozilla-central.
As highlighted in bold, there's an interesting positioning quirk with the subcomponents in the number input frame -- it looks like they're overlapping by 2px.
The scroll frame for the left portion has a width=11340
; and the button-container for the right portion has x=11340
(the same value) -- which makes sense, except that the left portion has a nonzero x
position -- it has x=120
(i.e. 2px). So its right edge will be at x=11460
which is 2px beyond the start of the button container.
This seems to confirm that there is indeed some overlap going on here.
Comment 5•3 years ago
|
||
I haven't verified this in a debugger since it's late, but I suspect the issue is here, where we compute the size of the textbox portion of the number input frame (the space that's not spin-up/down buttons)
// Offset the frame by the size of the parent's border
const auto& padding = aReflowInput.ComputedLogicalPadding(wm);
position.B(wm) = bp.BStart(wm) - padding.BStart(wm);
position.I(wm) = bp.IStart(wm) - padding.IStart(wm);
[...]
kidReflowInput.SetComputedISize(
std::max(0, aReflowInput.ComputedISize() - aButtonBoxISize));
Maybe aReflowInput.ComputedISize()
there includes the border/padding of the <input> element, and we're sizing the textbox as if we have all of that space available, but in fact we don't have the border available, because we position ourselves just inside of it (as noted in the position
adjustments above).
Comment 6•2 years ago
|
||
Set release status flags based on info from the regressing bug 1707070
Assignee | ||
Comment 7•2 years ago
|
||
I can take a look.
Assignee | ||
Comment 8•2 years ago
|
||
So I think the math is correct. The position is as it should, it's just that we don't account for the caret getting clipped. When there's no padding, we have a hack that moves the caret inside the scroll-frame...
Assignee | ||
Comment 9•2 years ago
|
||
Assignee | ||
Comment 10•2 years ago
|
||
This causes the scrollframe to be the right size and the caret clipping
code to work as we expect.
Depends on D131147
Assignee | ||
Comment 11•2 years ago
|
||
Depends on D131148
Assignee | ||
Updated•2 years ago
|
Comment 12•2 years ago
•
|
||
For my own recollection (and for future bugmail searchability): the reftest here works because we have:
user_pref("ui.caretBlinkTime", -1);
...which disables caret blinking.
https://searchfox.org/mozilla-central/rev/674b6582bafedc11fba6dc537769c88e9ed921d3/testing/profiles/reftest/user.js#88
(I couldn't remember the pref name, and at first I couldn't remember if that was a test-directory-specific pref setting, vs. if we set it globally. Looks like we set it globally, which makes sense.)
Comment 13•2 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4dbb84bd30ce Minor cleanups to text control layout. r=dholbert https://hg.mozilla.org/integration/autoland/rev/2d64a8ebacd0 Remove inline-end padding on inner text control frames if we have a button-box. r=dholbert https://hg.mozilla.org/integration/autoland/rev/ddab2094c6b9 Add a reftest. r=dholbert
Comment 14•2 years ago
|
||
Backed out 3 changesets (Bug 1740845) for causing reftest failures on caret-right.html.
Backout link
Push with failures
Failure Log
Assignee | ||
Comment 15•2 years ago
|
||
useDrawSnapshot doesn't draw carets apparently.
Comment 16•2 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0236fdb17160 Minor cleanups to text control layout. r=dholbert https://hg.mozilla.org/integration/autoland/rev/2ac779401602 Remove inline-end padding on inner text control frames if we have a button-box. r=dholbert https://hg.mozilla.org/integration/autoland/rev/4575e14b836e Add a reftest. r=dholbert
Comment 17•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0236fdb17160
https://hg.mozilla.org/mozilla-central/rev/2ac779401602
https://hg.mozilla.org/mozilla-central/rev/4575e14b836e
Updated•2 years ago
|
Updated•2 years ago
|
Description
•