294934 - When making app layouts using CSS and DIVs, sometimes the sizes are miscalculated

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[marcel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050519 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050519 Firefox/1.0+

In the attached testcase a nested structure of DIVs is used to generate a multi
column, multi row layout. The area that has a red border around it needs to be
filled with it's content.

The file displays correctly in Firefox 1.0 / Opera 8 / IE5+

Reproducible: Always

Steps to Reproduce:
1. Load the attached file
2. The red area should be filled with two colored rectangular areas (but it doesn't)

Actual Results:  
Described in the summary

Expected Results:  
Described in the summary

Comment 1

[marcel]

Attachment: Testcase for the reported bug

Comment 2

[Martijn Wargers (dead)]

Attachment: testcase2

Minimal testcase of what I think is the cause of the problem here.

Comment 3

[Martijn Wargers (dead)]

This regressed between 2005-03-21 and 2005-03-22.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-21+05%3A00%3A00&maxdate=2005-03-22+10%3A00%3A00&cvsroot=%2Fcvsroot
The only bug which seems likely to me what could have caused this is bug 282754.

When I remove the overflow:scroll of the container frame in the testcase, the
bug disappears.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Isn't that behaviour correct for the overflow case?

http://www.w3.org/TR/CSS21/visuren.html#position-props
Note: For absolutely positioned elements whose containing block is based on a
block-level element, this property is an offset from the padding edge of that
element.

If so, then we're actually incorrect for the normal case.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase3

(In reply to comment #4)
> Isn't that behaviour correct for the overflow case?
Yes, seems like it. But then Opera8 and IE6 are doing it wrong (and
Mozilla1.7).
That might give problems.
Also, current trunk builds do it still incorrectly for overflow:visible cases
and top and left properties. You can see that with this example where the
containing block has a padding of 20px;

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

dbaron, hixie --- having absolute positioning being relative to the padding-edge
of a block container is obviously in the spec for a reason, but it seems major
browsers don't do it that way. Can you confirm that it should be that way, will
remain that way and we should change behaviour to suit?

Comment 7

[Hixie (not reading bugmail)]

The padding edge is the edge between the padding and the border. This is what
the browsers I've tested do. Where's the problem?

Comment 8

[Mihai Sucan [:msucan]]

Attachment: very simple test case

Hello!

I have bumped into this regression when I tested the 2005-07-11 nightly build
of Firefox 1.0+. It's really improved and I like the many bug fixes.

Yet, due to this regression my site no longer looks properly.

I have attached a test case. As more test cases I see the more I believe it's a
regression in the browser. I don't believe all the other browsers do this
wrong.

Here's why:

1. Look at the red box in this test case. It's badly positioned only on the
right. On the top it's properly positioned even in Firefox 1.0+.
2. This bad rendering is only activated when overflow:hidden.

If some developer would have wanted to correct a suposed bad implementation of
absolutely positioned elements, then he would have made it work with top,
bottom and left. Plus, he would have made it work with overflow: visible. It's
probably just a regression caused by fixing or implementing something.

http://www.w3.org/TR/CSS21/visuren.html#position-props
"For absolutely positioned elements whose containing block is based on a
block-level element, this property is an offset from the padding edge of that
element."

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

The position and size of an element's box(es) are sometimes calculated relative
to a certain rectangle, called the containing block of the element. The
containing block of an element is defined as follows:
[...]
4. If the element has 'position: absolute', the containing block is established
by the nearest ancestor with a 'position' of 'absolute', 'relative' or 'fixed',
in the following way:
[...]
2. Otherwise, the containing block is formed by the padding edge of the
ancestor."

Reading these two quotes from the CSS 2.1 specification it almost made me
believe Firefox 1.0+ nightly builds actually fixed something about absolutely
positioned block-level elements.

http://www.w3.org/TR/CSS21/box.html#padding-edge
"The padding edge surrounds the box padding. If the padding has 0 width, the
padding edge is the same as the content edge."

Reading this ... I am not so sure :).

So, you guys go ahead and please fix the regression.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #7)
> The padding edge is the edge between the padding and the border. This is what
> the browsers I've tested do. Where's the problem?

Ah oops. Sorry, my bad.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Really simple and obvious fix ... mComputedWidth/Height are the content
width/height, we need to include padding.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 189349 [details] [diff] [review]
fix

Fixes standards-compliance, web-compatibility regression

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 189349 [details] [diff] [review]
fix

Could we add an assert in this case that aLastRS has block-level display?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

sure, OK

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

sure, OK

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in