Closed Bug 424710 Opened 16 years ago Closed 16 years ago

Layout change (and unexpected horizontal scrollbar) with this testcase

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: stevee, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(5 files)

Layout with the 20071204_1843 (note right hand side) (no horiz scrollbar)
40.14 KB, image/png
Details
Layout with the 20071204_1909 (note right hand side) (horiz scrollbar now present)
39.97 KB, image/png
Details
testcase
245 bytes, text/html
Details
grotesque hack
5.38 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
testcase
303 bytes, text/html
Details 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre ID:2008032204

1. New profile, start firefox
2. Visit https://bugzilla.mozilla.org/attachment.cgi?id=311290

Expected:
- No horizontal scrollbar

Actual:
- Horizontal scrollbar

There is a layout change between these two builds:
 - 20071204_1843_firefox-3.0b2pre.en-US.win32
 - 20071204_1909_firefox-3.0b2pre.en-US.win32

Checkins to module PhoenixTinderbox between 2007-12-04 18:43 and 2007-12-04 19:09 :

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-04+18%3A43&maxdate=2007-12-04+19%3A09&cvsroot=%2Fcvsroot

Due to bug 375304 or bug 406568.

TBH I don't know what the expected layout is, but the 20071204_1843 layout is the same as the Firefox 2 layout, and the 20071204_1909 layout is different, so something has changed and I'm always suspicious of change ;-)
Flags: blocking1.9?
Probably bug 375304. This does look bad.
This is at all related to bug 423312 ?

Roc can you take this and get us a fix + some reftests?
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
This horizontal (and vertical) scroll bar issue is due to a bug in "right" and "bottom" align (position:absolute) when the html element has a margin, border or padding, as described in bug 424701.

The problem here is that CalculateContainingBlockSizeForAbsolutes walks all the way up to the root scrollframe and calculates the containing block size based on that, i.e. the size includes the margins of the <html> element. Unfortunately the absolute frame is still positioned relative to the <html> element's content-rect (this is the real bug, it should be positioned relative to the initial containing block, i.e. the canvas frame that is the child of the root scrollframe and the parent of the <html> element's block frame, but this is too much to fix for 1.9). So we position relative to a right edge at the <html> element's content-rect plus the width of the viewport...

The quick fix for this is to adjust the way CalculateContainingBlockSizeForAbsolutes walks up the frame tree so it stops at the canvas frame and doesn't try to be clever here.
The real fix is to rework abs-positioning so that it doesn't apply to just blocks, and make the canvas frame the root abs-pos container. We probably have a bug on that refactoring somewhere. All I'll try to do here is restore parity with Firefox 2/Gecko 1.8.
Attached file testcase — 
Unfortunately Firefox 2 was really messed up. It actually tried to get the edge for 'bottom' from the viewport, but not the edge for 'right', as this testcase shows, and it actually has a version of this bug for 'bottom'. So getting back to that exact behaviour seems a bit pointless and also sad. But getting to a full fix is not practical right now. So I need to think about what the best behaviour for Firefox 3 is.
Attached patch grotesque hack — — Splinter Review 
Mimicking Firefox 2 is probably the best option here. It's easy to do, even though it sucks to write code to emulate bugs.

I don't want to test the exact behaviour we're aiming for here, since it's wrong. The test just checks that we don't trigger this bug by overflowing horizontally when we shouldn't ... so it will continue to pass when we do a real fix to make abs-pos frames use the initial containing block as their containing block.
Attachment #312009 - Flags: superreview?(dbaron)
Attachment #312009 - Flags: review?(dbaron)
Whiteboard: [needs review]
Comment on attachment 312009 [details] [diff] [review]
grotesque hack

A little bit scary, but r+sr=dbaron.

Could you also test compatibility with Fx2 / other browsers for the cases of:

left:0; right:0;width:auto;

left:0;width:100%;

to make sure this isn't making us less compatible?
Attachment #312009 - Flags: superreview?(dbaron)
Attachment #312009 - Flags: superreview+
Attachment #312009 - Flags: review?(dbaron)
Attachment #312009 - Flags: review+
Also, maybe cite bug 425432 in the XXX comments unless you can find a better bug to cite?
Attached file testcase — 
This tests what David asked about...
Here's how this looks in various browsers:

IE7 quirks mode:
  root element margin ignored, useless vertical scrollbar displayed inside the root element border, yellow <div> completely missing, blue <div> starts at the <html> padding edge but ends before the scrollbar. Pretty much a total loss.

IE7 standards mode:
  root element margin and border ignored, otherwise fine.

Firefox 2 standards and quirks mode:
  <div>s positioned and sized relative to <html> padding edges, otherwise fine.

Firefox 3 before patch, standards and quirks mode:
  <div>s positioned relative to <html> padding edges and sized too big so they overflow to the right (this bug).

Firefox 3 with patch, standards and quirks mode:
  Same as Firefox 2.

Safari 3.1 quirks mode:
  <div>s are positioned and sized relative to the viewport edge --- correct as per spec, AFAIK.

Safari 3.1 standards mode:
  root element margin and border ignored, otherwise fine.

Opera 9.50beta quirks and standards mode:
  root element margin and border ignored, otherwise fine.
So I can verify that this patch makes us consistent with Firefox 2 and doesn't change our (in)compatibility with other browsers.

I'm surprised that Opera, Safari and IE are suppressing the root element margin and border in standards mode. I'm not aware of anything in the spec that requires or allows that. I sent mail to www-style to check.
(In reply to comment #15)

Safari (3.1) and Opera (9.5) follow 10.1, I think:

Under point 4. 'If there is no such ancestor, the containing block is the initial containing block'

http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

Yeah sure, abs-pos elements should use the initial containing block as their containing block. But they're not rendering the root element margin and border *at all*.
Oh, they do, but it is covered by the yellow box (there is no in-flow content on your test page). Add a paragraph with a few lines text in your test case, and you'll see the green border peeping through from under the yellow box.
Oh you're absolutely right! Silly me.
Checked in
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs review]
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9pre) Gecko/2008042705 Minefield/3.0pre ID:2008042705 and the testcases from this bug.

--> Verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: