Closed
Bug 296722
Opened 20 years ago
Closed 20 years ago
[FIXr]fieldset with display:inline way too high
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
mozilla1.8beta3
People
(Reporter: 3.14, Assigned: bzbarsky)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
384 bytes,
text/html
|
Details | |
1.57 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
asa
:
approval1.8b3+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050605
Pages which have a fieldset with display:inline render way too high. See, e.g.,
the page in URL.
pi
Reporter | ||
Comment 1•20 years ago
|
||
Minimal testcase in valid HTML.
pi
Reporter | ||
Comment 2•20 years ago
|
||
http://www.wien.gv.at/amtshelfer/finanz.html does not have the same problem as
http://www.wien.gv.at/amtshelfer/. The (only?) difference is that the former is
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> while the latter is
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">.
pi
Reporter | ||
Updated•20 years ago
|
Comment 3•20 years ago
|
||
Yes. The one renders in quirks mode and the other in standards compliant mode
(the one with the full doctype). Looks like invalid to me...
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Form Controls
QA Contact: ian → layout.form-controls
Reporter | ||
Comment 4•20 years ago
|
||
What would be invalid there if something renders unreasonable in quirks mode? It
simply breaks pages.
And why assign to nobody?
pi
Comment 5•20 years ago
|
||
This works with 2005-01-31 build, it fails with 2005-02-01 build.
This is a regression from bug 240571.
Blocks: 240571
Updated•20 years ago
|
Keywords: regression
![]() |
Assignee | |
Comment 6•20 years ago
|
||
Argh. The problem, of course, is that once the fieldset is inline the 100% ends
up being 100% of the viewport.
Given that we don't actually support making <fieldset> inline (we construct the
same exact frame for it), perhaps we should just set it to "display:block
!important"? Alternately, perhaps we should set fieldset-content to
display:inherit, and if people style their fieldsets in silly ways they can deal
with floats leaking out of the fieldset, etc.... Not sure what this would break....
All that said, I don't understand why quirks makes a difference here. The code
in CalcQuirkContainingBlockHeight should be hitting the
1528 else {
1529 break;
1530 }
case when we reach the fieldset frame...
Perhaps the fieldset is not ending up as the containing block here?
Flags: blocking1.8b3?
![]() |
Assignee | |
Comment 7•20 years ago
|
||
Attachment #185444 -
Flags: superreview?(dbaron)
Attachment #185444 -
Flags: review?(dbaron)
Comment 8•20 years ago
|
||
If 'fieldset' always acts as 'block' then we might as well make it display:block
all the time as well.
![]() |
Assignee | |
Comment 9•20 years ago
|
||
> If 'fieldset' always acts as 'block'
I just checked; it doesn't _quite+ do that, actually. It acts most like a
replaced element (so setting it to display:inline will give you something that
doesn't cause a line-break but looks like a block to everything inside it).
More or less like <button>.
Comment 10•20 years ago
|
||
Ok, nevermind then.
Attachment #185444 -
Flags: superreview?(dbaron)
Attachment #185444 -
Flags: superreview+
Attachment #185444 -
Flags: review?(dbaron)
Attachment #185444 -
Flags: review+
![]() |
Assignee | |
Comment 11•20 years ago
|
||
Comment on attachment 185444 [details] [diff] [review]
This ought to fix it
Requesting 1.8b3 approval; this should be a pretty safe fix for this
regression.
Attachment #185444 -
Flags: approval1.8b3?
![]() |
Assignee | |
Updated•20 years ago
|
Assignee: nobody → bzbarsky
OS: other → All
Priority: -- → P1
Hardware: PC → All
Summary: fieldset with display:inline way too high → [FIXr]fieldset with display:inline way too high
Target Milestone: --- → mozilla1.8beta3
Updated•20 years ago
|
Attachment #185444 -
Flags: approval1.8b3? → approval1.8b3+
![]() |
Assignee | |
Comment 12•20 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Flags: blocking1.8b3?
Comment 13•20 years ago
|
||
*** Bug 296929 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 14•20 years ago
|
||
Great, works in 2005062405. Thanks.
pi
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•