Closed Bug 1698043 Opened 2 months ago Closed 2 months ago

Input Field of type Number, placeholder blocked by arrows if text-align:right

Categories

(Core :: DOM: Core & HTML, defect)

Firefox 86
defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox88 --- fixed

People

(Reporter: czwkoh, Assigned: emilio)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 2 obsolete files)

Attached image firefoxTestNoVal.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36

Steps to reproduce:

Steps to reproduce:
(1) Run a simple html page with a input with properties type="number" and placeholder = "0"
(2) Set input css to text-align: right
(3) View it with the browser

Actual results:

Condition: when the input has no value -
The placeholder is aligned right, parked just left beside the arrows of the number input field

Expected results:

Condition: when the input has no value -
The placeholder is aligned right, but hidden behind the arrows of the number input field. Hiding the arrows with css will show it is behind the arrow.
Adding actual values will cause the values to appear normally.

Attached Image shows a input with type number and text-align: right

This bug happens in chrome 89.0.4389.82 as well (you have to hover to see it get blocked) but does not happen in Safari.

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

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
data:text/html,<input type=number placeholder=0 style="text-align:right">

Confirmed. Looks like this is covered by nsNumberControlFrame::CreateAnonymousContent:

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(emilio)

Should be much simpler and doesn't need to deal with the different
stuff. We already have pseudo-classes for this, :autofill and
:placeholder-shown.

I initially wrote this because this is the only limitation that forces
us to have the placeholder text as a direct child of the text control
frame. In the end I kept that as-is, but this simplification is still
worth it.

We remove dom.placeholder.show_on_focus because it doesn't behave
correctly (it doesn't match the :placeholder-shown pseudo-class and it
should). It was introduced in bug 807613 and never turned to false by
default. I suspect nobody will miss this, but if somebody complains
about it we can reintroduce it properly (handling the pref in DOM
instead, changing the right state bits).

Assignee: nobody → emilio
Status: NEW → ASSIGNED

This should be a simpler setup. We keep every element being a direct
anon child of the text control, and special case the reflow of the
spinners / clear button, to subtract that size from the other elements.

This fixes the bug by ensuring that the editor and placeholder are sized
and positioned in exactly the same way.

Depends on D108304

Flags: needinfo?(emilio)
Summary: Input Field of type Number, placeholder blocked by arrows if text-alight:right → Input Field of type Number, placeholder blocked by arrows if text-align:right
Blocks: 1654288
Blocks: 1698315

Comment on attachment 9208860 [details]
Bug 1698043 - Manage placeholder and autofill preview visibility using CSS rather than custom code. r=masayuki

Revision D108304 was moved to bug 1698315. Setting attachment 9208860 [details] to obsolete.

Attachment #9208860 - Attachment is obsolete: true
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2bc9ef937528
Simplify <input type=number/search> layout to fix this bug and make ::-moz-complex-control-wrapper unnecessary. r=dholbert

Thanks! that is bug 1698332, will annotate the new test for search inputs as failing on Android for now.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/44eddd702c0a
Simplify <input type=number/search> layout to fix this bug and make ::-moz-complex-control-wrapper unnecessary. r=dholbert
Duplicate of this bug: 1656798
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Blocks: 1698397
Regressions: 1698821

There's no anonymous textfield since a long time ago.

Depends on D108654

Comment on attachment 9209496 [details]
Bug 1698043 - Remove dead GetNumberControlFrameForTextField. r=dholbert

Revision D108655 was moved to bug 1698821. Setting attachment 9209496 [details] to obsolete.

Attachment #9209496 - Attachment is obsolete: true

Per discussion on matrix, it looks like we could perhaps upstream some of these tests to wpt.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)

Seems like a reasonable thing to expect that the placeholder renders at
the same place as the text it's a placeholder for.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/536ffb297e79
Upstream the test for this bug to WPT. r=layout-reviewers,jfkthame
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/28411 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Regressions: 1707070
You need to log in before you can comment on or make changes to this bug.