965237 - right padding ignored on text/password fields where values overflow content

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Shane Tomlinson [:stomlinson]]

Attachment: Test case showing problem with both text and password fields.

I have only tested with text/password fields. When a text or password field has a fixed width, and a right/left padding applied, the right padding is ignored if the field value overflows the contents.

Attached is a test case and a screen clip showing the problem and the layout as shown in the Firefox developer tools.

Comment 1

[Shane Tomlinson [:stomlinson]]

Attachment: Screen Shot 2014-01-29 at 13.58.51.png

Screen shot showing problem and layout as seen in the Firefox developer tools.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Looks like a regression from bug 157846.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note that IE11 does _not_ have this behavior, though in general it does have the right "content can overflow into the padding" behavior for scrollframes.

Comment 4

[Mats Palmgren (inactive)]

(In reply to Boris Zbarsky [:bz] from comment #3)
> Note that IE11 does _not_ have this behavior, though in general it does have
> the right "content can overflow into the padding" behavior for scrollframes.

Yes, but note also that the _left_ padding stays in view when scrolling
to the end, in both IE/Chrome.  So they have changed the clipping edge
to be the content edge instead of the padding edge[1], and then it follows
that the padding stays in view.  So this layout does _not_ violate the
Box Model[2] (unlike the "add padding around the child overflow" that
Chrome does for blocks).

[1] http://www.w3.org/TR/CSS21/visufx.html#overflow-clipping
[2] http://www.w3.org/TR/CSS2/box.html

To the extent CSS says anything about form controls or the internal
rendering of replaced elements at all of course ;-)

Comment 5

[Benjamin Kerensa [:bkerensa]]

Would you be able to look into this since you worked on bug 157846?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Mats, Boris, do you think we should change the clipping edge like IE and Chrome do?

I wonder how much of a problem this really is. It's a behavior change, but is showing the extra text really bad?

Comment 7

[Mats Palmgren (inactive)]

I think it looks pretty bad.  For example if your scroll using RIGHT
and then LEFT you can't get back to the start, or so it seems anyway
since your memory tells you there used to be a padding at the start.

Good news is I have a WIP that implements this, and it might help with
Google Translate too...

Comment 8

[Mats Palmgren (inactive)]

Attachment: Make overflow-clip-box:content-box be the default for <input type=text/password/number> and <textarea>.

This fixes the reported problem and also translate.google.com (bug 961347).

Comment 9

[Mats Palmgren (inactive)]

Attachment: Make overflow-clip-box:content-box be the default for <input type=text/password/number> and <textarea>.

Now with the fuzzy-if() annotation on the test I intended.

Comment 10

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c84d530c9a51

Comment 11

[(no longer active)]

I had to back this out because I needed to back out bug 966992.

Comment 12

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/66c3d7b1701b

Comment 13

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/66c3d7b1701b

Comment 14

[Alice0775 White]

Please uplift this to Aurora29.0a2 to fix bug 961347

Comment 15

[Mats Palmgren (inactive)]

Comment on attachment 8371541 [details] [diff] [review]
Make overflow-clip-box:content-box be the default for <input type=text/password/number> and <textarea>.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 157846
User impact if declined: broken layout of <input type=text/password/number> and <textarea>, high visibility, breaks Google translate (bug 961347) for example
Testing completed (on m-c, etc.): on m-c since 2014-02-23
Risk to taking this patch (and alternatives if risky): the patches in bug 966992 are also needed to fix the regression, and together they are medium risk.  The alternative is to backout bug 157846.
String or IDL/UUID changes made by this patch: none

The request is for all patches in this bug, and bug 966992

Comment 16

[Mats Palmgren (inactive)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/20f7051ed500

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8371541 [details] [diff] [review]
Make overflow-clip-box:content-box be the default for <input type=text/password/number> and <textarea>.

>@@ -131,16 +132,17 @@ textarea::-moz-placeholder {
>   padding: inherit !important;
>   margin: 0px;
>   text-decoration: inherit;
>   -moz-text-decoration-color: inherit;
>   -moz-text-decoration-style: inherit;
>   display: inline-block;
>   ime-mode: inherit;
>   resize: inherit;
>+  overflow-clip-box: inherit;
> }

I'm curious why this isn't !important like the overflow-x and overflow-y rules below it are.

Comment 18

[Mats Palmgren (inactive)]

I suspect that changing 'overflow' on a placeholder inside a text control
could produce rather weird results.  Changing 'overflow-clip-box', OTOH,
seems somewhat useful and at least it will produce the expected results.
I don't see a reason why it needs to be !important.
(Note that 'overflow-clip-box' isn't exposed to web content yet though.)

Comment 19

[Boris Zbarsky [:bzbarsky]]

Mats, is there a reason *|*::-moz-fieldset-content doesn't inherit overflow-clip-box?

Comment 20

[Mats Palmgren (inactive)]

Not that I can think of.  It seems I just missed that one.
Filed bug 1226278.