1715291 - Input padding-inline-end covers/hides the last characters in the input

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Joris Debonnet]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

1. Make an html file with the following contents:
   <input style="padding-right: 50px; width: 170px;" value="The right side is covered.">
2. Open it, and try to see the last letter of the value. Note that the value is too long to fit in the available space, so you'll have to move the cursor to the right, using keyboard or mouse (by select-dragging to the right).

Actual results:

Moving the cursor to the right does not yield the expected result. The cursor just disappears out of view, "behind" the padding.

As soon as I add extra characters at the end of the value however, the behavior will snap into working correctly. This happens as soon as the value would not even fit in the input anymore if there was no padding: then the value becomes 'horizontal-scrollable' using the cursor or mouse.

Expected results:

The user should always be able to get to the end of the input. This used to work before Firefox 89, I believe, and it also still works in other browsers.

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

[christopher-hannusch]

I can confirm this bug. This even happens with the search field on top of this page. Pretty easy to reproduce.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Attachment: The report's test case

Comment 4

[Joris Debonnet]

Is anyone able to fix this for the next patch version?

It's quite disruptive in some applications that have for example an icon on the right side of the input, using padding to prevent the input text to cover that icon. If you typed something that just ends inside that padding, you have no way to see the end of what you just typed, so you have to use very counter-intuitive tricks to continue writing (adding some spaces, or removing what you just typed in order to try typing blind again, ...)

I'll upload a screenshot of the issue in a live application.

Comment 5

[Joris Debonnet]

Attachment: Screenshot showing the issue in a live application

The word 'typo' at the end is not fully visible and cannot be reached. So I might have typed typa, or typp, or typi, or ...

(the new blue border around the active input also does not play well with this design, ... but that's not the topic of this bug)

Comment 6

[Troy Haran]

Looks like this issue was introduced in version 89 and is still an issue in the latest version at the time of this post (91). Is this issue currently being tracked by devs? Could we get an ETA on when this may be fixed?

Comment 7

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

mozregression finds this push range introducing the regression https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=01686a5407acd57fb6685406d756926ea87164b8&tochange=cb4178b436e73edefbb5efcd5c4f3df5262e7a54

I bet bug 1696885 is the cause. I'll take a look.

Comment 8

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Attachment: Bug 1715291 - Fix text in <input> is clipped by inline-end padding.

The fix in Bug 1696885 is not correct when the width of the text in
<input> is shorter than the width of the <input>, but is long enough to
be covered by its inline-end padding.

This patch's idea is similar to the old code [1] before applying bug
1696885, but only tweak the scrollable overflow area in the inline axis.

[1] https://searchfox.org/mozilla-central/rev/c3ee9188d2f9020764db9daf8fa47a07fa3311c9/layout/generic/nsGfxScrollFrame.cpp#785-806

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d4d3c40a747d
Fix text in <input> is clipped by inline-end padding. r=emilio

Comment 12

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

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

Comment 13

[Marian-Vasile Laza]

Backed out changeset d4d3c40a747d (Bug 1715291) for causing Linting failures.
Backout link
Push with failures
Failure Log

Comment 14

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

Upstream PR was closed without merging

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14b91d2e1dee
Fix text in <input> is clipped by inline-end padding. r=emilio

Comment 16

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Fixed the wpt lint by including ahem.css in wpt references files.

Comment 17

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/14b91d2e1dee

Comment 18

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

Upstream PR merged by moz-wptsync-bot

Comment 19

[Ryan VanderMeulen (PTO, back 6-April)]

Please nominate this for Beta and ESR91 approval when you get a chance.

Comment 21

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Comment on attachment 9237263 [details]
Bug 1715291 - Fix text in <input> is clipped by inline-end padding.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is regressed by bug 1696885, and has been reported by different users.
• User impact if declined: When <input> has padding-right and the text length is between width and width - padding-right, the text is clipped. There's no way to reach the end of the text, either by moving cursor or setting scrollLeft via JS.
• Fix Landed on Version: 93
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The code path affects only <input> and <textarea> elements, and is covered by WPT tests.
• String or UUID changes made by this patch: None

Comment 22

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

The patch landed in nightly and beta is affected.
:TYLin, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 23

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Comment on attachment 9237263 [details]
Bug 1715291 - Fix text in <input> is clipped by inline-end padding.

Beta/Release Uplift Approval Request

• User impact if declined: When <input> has padding-right and the text length is between width and width - padding-right, the text is clipped. There's no way to reach the end of the text, either by moving cursor or setting scrollLeft via JS.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The code path affects only <input> and <textarea> elements, and is covered by WPT tests.
• String changes made/needed: None

Comment 24

[Ryan VanderMeulen (PTO, back 6-April)]

Comment on attachment 9237263 [details]
Bug 1715291 - Fix text in <input> is clipped by inline-end padding.

Approved for 92.0b8 and 91.1esr.

Comment 25

[Ryan VanderMeulen (PTO, back 6-April)]

https://hg.mozilla.org/releases/mozilla-beta/rev/255523cb6679

Comment 26

[Ryan VanderMeulen (PTO, back 6-April)]

https://hg.mozilla.org/releases/mozilla-esr91/rev/3cef3c2717b6