Closed
Bug 55832
Opened 24 years ago
Closed 24 years ago
css "width: 100%" rendering incorrectly for button elements
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
mozilla0.6
People
(Reporter: djoham, Assigned: rods)
Details
(Whiteboard: [rtm++] fix in hand, r=ianh, a=beng)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20000921
BuildID: 2000091312
if you use the css "width: 100%" for a button who's parent is a table cell, the
button will be rendered incorrectly. The button will be sized to the outside
edge of the cell not to the inside edge as it should be.
Reproducible: Always
Steps to Reproduce:
1) open test case I'll submit
2) Note that the button element is not sized correctly
3) Note that the input element is sized correctly with the same CSS rule
Actual Results: Notice that the button element is not rendered as it should be
Expected Results: I would expect the two elements (button and input) to be
rendered exactly the same for this test case.
I believe that this regression occurred in the big HTML.css checkin a couple of
weeks ago. Build 2000092008 renders the test case correctly. The daily build for
the day after does not. I'll try to dig into the html.css file a little deeper
tonight and see if I can find what's up. In the mean time, anybody have any
ideas?
Assignee | ||
Comment 2•24 years ago
|
||
won't make it in for rtm - futuring
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Rod, I'm not sure what the rules are here. I was planning on taking a close look
at this tonight and seeing if I could come up with a safe patch to HTML.css that
addresses this problem. The IFRAME element also renders incorrectly with the
same css. When you say "won't make it in to RTM" does that mean it won't even if
external developers (i.e. me) come up with a safe patch? I have a vested self
interest in getting this fixed. It makes my pages look really bad.
TIA
David
There is a simple one line fix for this problem. In html.css, add the following
attribute to the button element:
-moz-box-sizing: border-box;
The width problem also affects IFRAMES. The same fix addresses that element as well.
Here's the issue:
html.css from build 2000092008 had this attribute for buttons (but not IFRAMES,
which have always been broken). All later builds have it removed. Why was that
attribute taken out? Can it be put back in? I'd like to get more information on
this before I start asking for this fix to be labeled RTM+.
I can make a patch tonight that wraps these fixes up neatly. However, will I be
breaking anything. I can't see how (and things are working fine now with manual
patches applied), but I'll defer to the experts.
David
Comment 5•24 years ago
|
||
Eek, my bad. I must have dropped the one declaration while rejigging ua.css.
657 /* buttons */
658 button,
659 input[type="reset"],
660 input[type="button"],
661 input[type="submit"] {
662 border: 2px outset ButtonFace;
663 background-color: ButtonFace;
664 color: ButtonText;
665 padding: 1px 1px 1px 1px;
666 font: button;
667 cursor: default;
668 white-space: pre;
-moz-box-sizing: border-box; <<<<<< add this line!
669 -moz-user-select: none;
670 -moz-binding: none;
671 }
I don't think we should fix it for IFRAME though. IFRAMEs are not common enough
on the web for us to use '-moz-box-sizing' with them. Let's get web authors to
use IFRAMEs correctly per CSS if possible.
Could you attach the diff which just does the button case? Thanks.
Keywords: rtm
Whiteboard: fix in hand
I'll attach the patch tonight.
You say "use IFRAMES correctly via CSS". How would I do that without using the
-moz-box-sizing if it has the same problem as the button element? Is there a CSS
attribute other than width: 100% that would get the IFRAME to scale to the width
of its container but not beyond? Why would applying that attribute to the IFRAME
be a bad idea?
As an aside, is there anywhere these mozilla-specific css attributes are
documented? I really don't even know what moz-box-sizing even does.
David
Comment 7•24 years ago
|
||
What you want is:
iframe { display: block; width: auto; }
It's a bad idea to use our extensions because they are non-standard.
No, we don't have good documentation yet. There are bugs open on this (search
the documentation product). -moz-box-sizing decides what the definition of
the 'width' property will be relative to: the content box or the border box.
Per CSS, it should be the content box.
OS: Linux → All
Hardware: PC → All
Target Milestone: Future → mozilla0.6
Comment 8•24 years ago
|
||
The fix is straight foward and simple for the button case and we have been
running for months with the -moz-box-sizing: border-box for input and button
elements. Not having this fix risks other regressions which we have not caught
since it is such as recent change (regression) that we are not using
-moz-box-sizing.
Marking [rtm need info]. Waiting for patch, approval, super-review. We need to
get the fix and superreview soon (Next day or so). or I doubt that PDT will
consider this fix for RTM.
Whiteboard: fix in hand → [rtm need info]fix in hand
Reporter | ||
Comment 10•24 years ago
|
||
Ian,
I'd love to use auto, but it either doesn't work in Mozilla or I'm completely
reading the CSS spec wrong. I've logged bug 55927 to discuss and clear the issue
up once and for all. Logging another bug also clears this one up and gets it
back to its original purpose.
Thanks
David
Comment 11•24 years ago
|
||
r=ianh assuming that patch hits the button rule (please do -u diffs in future,
thanks! :-) ).
Whiteboard: [rtm need info]fix in hand → [rtm need info] fix in hand
Comment 12•24 years ago
|
||
Ben, can you a= this please?
Comment 13•24 years ago
|
||
a=
Updated•24 years ago
|
Whiteboard: [rtm need info] fix in hand → [rtm+] fix in hand, r=ianh, a=beng
Comment 14•24 years ago
|
||
marking rtm++
Whiteboard: [rtm+] fix in hand, r=ianh, a=beng → [rtm++] fix in hand, r=ianh, a=beng
Comment 15•24 years ago
|
||
Kevin or Rod: Could you check this in when the branch opens please? Cheers!
Comment 16•24 years ago
|
||
fix checked in on branch. I assume it needs to go into the trunk, also?
Keywords: rtm
Whiteboard: [rtm++] fix in hand, r=ianh, a=beng → fix in hand checked in to branch, r=ianh, a=beng
Comment 17•24 years ago
|
||
fix checked in to branch and trunk (if it wasn't supposed to go into the trunk,
let me know).
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand checked in to branch, r=ianh, a=beng → [rtm++] fix in hand, r=ianh, a=beng
Comment 18•24 years ago
|
||
Build: 2000-10-16-09 MN6
Platform: WinNT
The button element renders correctly.
Status: RESOLVED → VERIFIED
Comment 19•24 years ago
|
||
Please verify All/All bugs on all platforms, in both the trunk and the branch.
You need to log in
before you can comment on or make changes to this bug.
Description
•