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

RESOLVED FIXED in Firefox 29

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: stomlinson, Assigned: mats)

Tracking

({regression})

29 Branch
mozilla30
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox28 unaffected, firefox29+ fixed, firefox30 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Created attachment 8367277 [details]
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.
(Reporter)

Comment 1

4 years ago
Created attachment 8367278 [details]
Screen Shot 2014-01-29 at 13.58.51.png

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

Updated

4 years ago
Version: unspecified → 29 Branch
Attachment #8367277 - Attachment mime type: text/plain → text/html
Looks like a regression from bug 157846.
Blocks: 157846
tracking-firefox29: --- → ?
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.
Keywords: regression
(Assignee)

Comment 4

4 years ago
(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 ;-)
Would you be able to look into this since you worked on bug 157846?
Flags: needinfo?(roc)
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?
Flags: needinfo?(roc)
(Assignee)

Comment 7

4 years ago
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...
Assignee: nobody → matspal
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Updated

4 years ago
Depends on: 966992
(Assignee)

Updated

4 years ago
Blocks: 961347
(Assignee)

Comment 8

4 years ago
Created attachment 8371434 [details] [diff] [review]
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).
Attachment #8371434 - Flags: review?(roc)
(Assignee)

Comment 9

4 years ago
Created attachment 8371541 [details] [diff] [review]
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.
Attachment #8371434 - Attachment is obsolete: true
Attachment #8371434 - Flags: review?(roc)
Attachment #8371541 - Flags: review?(roc)
Attachment #8371541 - Flags: review?(roc) → review+
status-firefox28: --- → unaffected
status-firefox29: --- → affected
tracking-firefox28: --- → ?
tracking-firefox29: ? → +
tracking-firefox28: ? → ---
(Assignee)

Comment 10

4 years ago
landing
https://hg.mozilla.org/integration/mozilla-inbound/rev/c84d530c9a51
Flags: in-testsuite+

Comment 11

4 years ago
I had to back this out because I needed to back out bug 966992.
(Assignee)

Comment 12

4 years ago
landing
https://hg.mozilla.org/integration/mozilla-inbound/rev/66c3d7b1701b
https://hg.mozilla.org/mozilla-central/rev/66c3d7b1701b
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30

Comment 14

4 years ago
Please uplift this to Aurora29.0a2 to fix bug 961347
Flags: needinfo?(matspal)
(Assignee)

Comment 15

4 years ago
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
Attachment #8371541 - Flags: approval-mozilla-aurora?
Flags: needinfo?(matspal)
status-firefox30: --- → fixed
Attachment #8371541 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 16

4 years ago
landing
https://hg.mozilla.org/releases/mozilla-aurora/rev/20f7051ed500
status-firefox29: affected → fixed
Blocks: 975062
(Assignee)

Updated

4 years ago
Blocks: 971955

Updated

4 years ago
Depends on: 1007065
Depends on: 990974
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.
Flags: needinfo?(mats)
(Assignee)

Comment 18

2 years ago
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.)
Flags: needinfo?(mats)
Mats, is there a reason *|*::-moz-fieldset-content doesn't inherit overflow-clip-box?
Flags: needinfo?(mats)
(Assignee)

Comment 20

2 years ago
Not that I can think of.  It seems I just missed that one.
Filed bug 1226278.
Flags: needinfo?(mats)
You need to log in before you can comment on or make changes to this bug.