Closed Bug 43086 Opened 20 years ago Closed 20 years ago

[FLOAT]non-table floats should carry to next line (un-quirk)

Categories

(Core :: Layout, defect, P1)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: dbaron)

References

Details

(Keywords: css1, testcase, Whiteboard: [fix in hand]QA: Does this affect top100 pages? [nsbeta3+])

Attachments

(1 file)

DESCRIPTION:  The quirk implement in bug 37657 should be only for tables, not 
for any floating elements.  There is no need to make this quirk for anything 
other than tables since MSIE5 does it only for tables, and therefore pages on 
the web depend on its presence only for tables.  I'd rather not break css1 
compliance too badly.

STEPS TO REPRODUCE:
 * load attachment in window narrower than 1000px

ACTUAL RESULTS:
 * both tests are left/right

EXPECTED RESULTS:
 * first test should be above/below, second should be left/right

BUGGY ON:
 * Win98 mozilla 2000-06-16

WORKS CORRECTLY ON:
 * Win98 MSIE5
Summary: [FLOAT]Floats should not stack horizontally → [FLOAT]non-table floats should carry to next line (un-quirk)
As per meeting with ChrisD today, taking QA.

Nominating for nsbeta3 to get judgement call from PDT: should we fix this 
(before FCS) or should we WONTFIX it? This will only impact legacy documents,
but it is unclear how much of an effect this 'bug' has.

If we do not fix this by nsbeta3 (and thus FCS) then there is no point fixing
it for future releases.
QA Contact: petersen → py8ieh=bugzilla
Ian - this bug is a quirk that we have that does not exist in older browsers. 
We don't want that.
Sure, ideally we don't. But given where we're at (namely, weeks from release), 
unless this actually affects real world pages then our time would be better 
spent fixing real standards compliance bugs.
Keywords: qawanted
Whiteboard: QA: Does this affect top100 pages?
This *is* a standards-compliance bug.  I think it would cause the boxacidtest to
fail in quirks mode.
BTW, this is also just a slight refinement to a previous fix -- do it only if
the tag name is table and the display property is table.

That is, in nsBlockReflowState::PlaceFloater, right after the first call to
GetCompatibilityMode, you should also get the tag name and (or perhaps or) the
display type, and change the logic from:

if (eCompatibility_NavQuirks != mode)

to

if ((eCompatibility_NavQuirks != mode) || (floaterDisplay->mDisplay != 
NS_STYLE_DISPLAY_TABLE))

or maybe also get the content from the frame and the tag from the content and
make sure it's a table tag before one decides not to do this...

If you're considering not doing this for beta3, assign it to me and I'll do
it...
You asked for it ;) - Since you know where to fix it, please make it good! 
Thanks David, since buster's still on vacation I would have had to deny it...

Also, approving for beta3 since David is going to fix it and feels it is 
critical.
Assignee: buster → dbaron
Whiteboard: QA: Does this affect top100 pages? → QA: Does this affect top100 pages? [nsbeta3+]
*** Bug 48226 has been marked as a duplicate of this bug. ***
Priority: P3 → P1
Have fix.
Status: NEW → ASSIGNED
Whiteboard: QA: Does this affect top100 pages? [nsbeta3+] → [fix in hand]QA: Does this affect top100 pages? [nsbeta3+]
PDT agrees P1 - david, can you check in ASAP please?
Fix checked in 2000-09-04 14:44 PDT.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
VERIFIED Win2K and Linux Comm M18 trunk builds 2000090609.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.