[FIX]legend positioning is incorrect when a :first-line rule matches containing fieldset

RESOLVED FIXED in mozilla1.9.1a2

Status

()

defect
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: ve3ll, Assigned: bzbarsky)

Tracking

Trunk
mozilla1.9.1a2
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(3 attachments)

Reporter

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

up til now legends were correctly positioned half way down a line
from top margin of containing fieldset ... now they are below it
and the comment zone of the example should appear at the bottom
of the layout .... beta 4 seemed ok 
check against opera/safari/msie for appearance

Reproducible: Always

Steps to Reproduce:
1. look at the demo page
2. compare with opera/safari/msie
3. compare with FF 2
Actual Results:  
misplacement of legends and comment box

Expected Results:  
similar to other browsers
Reporter

Comment 1

11 years ago
the design of the fuel calculator uses floated divs and lists
maybe that is where is is

http://home.cogeco.ca/~trains/rrsoft.htm#cal
done by same author uses old fashioned tables and the legend
positioning works ok there....

quirks occur when floated objects occur inside the frameset !!!! 
I see it as an old regression from Bug 300030.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Component: Layout → Layout: Form Controls
QA Contact: layout → layout.form-controls
Summary: legend positioning is incorrect -- regression error → legend positioning is incorrect when a :first-line rule matches containing fieldset
So the behavior *changed* when the reflow branch landed, but it was broken both before and after the reflow branch landing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I suspect the right thing to do here is to disable :first-line processing for the contents of fieldset, since it's not really clear what it should match.  Making it actually do something might be harder.
Comment 6 sounds good to me.  Both the old and new behavior are pretty clearly wrong...

On a separate note, I wonder whether the sheet's author realizes the inefficiency those styles introduce.  Ah, well.
Posted patch FixSplinter Review
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #331364 - Flags: superreview?(dbaron)
Attachment #331364 - Flags: review?(dbaron)
Summary: legend positioning is incorrect when a :first-line rule matches containing fieldset → [FIX]legend positioning is incorrect when a :first-line rule matches containing fieldset
Comment on attachment 331364 [details] [diff] [review]
Fix

It seems odd to me that the patch would look like this.  We're only supposed to support :first-line and :first-letter for the contents of blocks.  So shouldn't there be some existing check for block-ness?

But I suppose this is OK.

The test should have something between the {}, though, since we might at some point optimize such rules away.  Probably color:red, so that the test fails if :first-line does anything.
Attachment #331364 - Flags: superreview?(dbaron)
Attachment #331364 - Flags: superreview+
Attachment #331364 - Flags: review?(dbaron)
Attachment #331364 - Flags: review+
The existing check for block-ness is that we just look for a float containing block.  That is, we assume that the set of frames that are float containing blocks exactly matches the set of frames that should have first-line and first-letter.  I could change that, but it would be a lot more invasive...

I'll add a "color: red" to the test.
Checked in with that change.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
I had to check in a followup bustage fix: ShouldHaveFirstLineStyle didn't have a return statement at the end....
You need to log in before you can comment on or make changes to this bug.