Closed Bug 43086 Opened 20 years ago Closed 20 years ago
[FLOAT]non-table floats should carry to next line (un-quirk)
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.
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.
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. ***
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
You need to log in before you can comment on or make changes to this bug.