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)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8beta3

People

(Reporter: 3.14, Assigned: bzbarsky)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

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
Attached file Minimal valid testcase
Minimal testcase in valid HTML. pi
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
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
What would be invalid there if something renders unreasonable in quirks mode? It simply breaks pages. And why assign to nobody? pi
Keywords: testcase
This works with 2005-01-31 build, it fails with 2005-02-01 build. This is a regression from bug 240571.
Blocks: 240571
Keywords: regression
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?
Attachment #185444 - Flags: superreview?(dbaron)
Attachment #185444 - Flags: review?(dbaron)
If 'fieldset' always acts as 'block' then we might as well make it display:block all the time as well.
> 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>.
Ok, nevermind then.
Blocks: 296929
Attachment #185444 - Flags: superreview?(dbaron)
Attachment #185444 - Flags: superreview+
Attachment #185444 - Flags: review?(dbaron)
Attachment #185444 - Flags: review+
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: 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
Attachment #185444 - Flags: approval1.8b3? → approval1.8b3+
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking1.8b3?
*** Bug 296929 has been marked as a duplicate of this bug. ***
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.

Attachment

General

Created:
Updated:
Size: