Closed Bug 965237 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

29 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30
Tracking Status
firefox28 --- unaffected
firefox29 + fixed
firefox30 --- fixed

People

(Reporter: stomlinson, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

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.
Attached image Screen Shot 2014-01-29 at 13.58.51.png (deleted) —
Screen shot showing problem and layout as seen in the Firefox developer tools.
Version: unspecified → 29 Branch
Attachment #8367277 - Attachment mime type: text/plain → text/html
Looks like a regression from bug 157846.
Blocks: 157846
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
(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)
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
Depends on: 966992
Blocks: 961347
This fixes the reported problem and also translate.google.com (bug 961347).
Attachment #8371434 - Flags: review?(roc)
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)
I had to back this out because I needed to back out bug 966992.
https://hg.mozilla.org/mozilla-central/rev/66c3d7b1701b
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Please uplift this to Aurora29.0a2 to fix bug 961347
Flags: needinfo?(matspal)
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)
Attachment #8371541 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Blocks: 975062
Blocks: 971955
Depends on: 1007065
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)
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)
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.

Attachment

General

Created:
Updated:
Size: