260498 - nsGenericHTMLElement::offsetWidth returns different values for the root element

Status: NEW

(Core :: Layout, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Test the attached test case with for instance Mozilla 1.7.1 and the trunk. It
will easily show a **recent** change in the return value of foo.offsetWidth when
foo is the root of an HTML document...

This change _deeply_ impacts Composer, Nvu and will probably also impact all web
pages made for IE and using offsetWidth, offsetHeight. In Composer/Nvu, this
change is probably the origin of at least two new crashers related to resizing
and positioned elements.

It seems that before that change, the return values of GetOffsetWidth() and
GetOffsetHeight() for the root element were MAX'ed with the viewport's size and
this is not the case any longer.

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: test case showing difference between 1.7.1 and trunk

Comment 2

[Ludovic Hirlimann [:Usul]]

Daniel,
you should ask for the bug to be blocking 1.8a4.
If this is a regression then that keyword can be added.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> It will easily show a **recent** change in the return value of foo.offsetWidth

Most likely because we fixed our mis-sizing of the root element.  See bug
241694, bug 15405, bug 57906 (all fixed by revision 1.135 of nsHTMLFrame.cpp on
2004-04-30).  You can put a border on the root to see the difference in
rendering between 1.7 and trunk.  OffsetWidth is correctly reporting the size of
the root in both cases, but the size is different -- trunk is correct.

> This change _deeply_ impacts Composer, Nvu

If those want the size of the root element, they're still getting it.  If they
want some other quantity, why are they using offset* on the root?

> and will probably also impact all web pages made for IE and using offsetWidth,
> offsetHeight.

Almost none of these use the root, because it's harder to get than doing
document.body and because the body is treated like the root by IE for all
intents and purposes.  We've certainly had no bug reports on the scripting end
of this in the 5 months since the change happened.

> It seems that before that change, the return values of GetOffsetWidth() and
> GetOffsetHeight() for the root element were MAX'ed with the viewport's size 

No, before that change the actual rendered size of the root was stretched to
fill the viewport.  That's no longer done...

If there is a strong need, we could probably special-case offset* on the root to
keep the old behavior, but I question whether there is a need.

Removing regression keyword, since the offsetWidth behavior is correct in all
builds involved (shows the size of the element's box).

Comment 4

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

bz: see the effect on http://glazman.org/weblog/
the html element has a border. Why does the border stop on in-flow content's edge
and not below the positioned elements ? Don't the positioned elements belong to the
document and change its height?

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This **is** a regression and here is why :

(a) offsetWidth and offsetHeight are **not** standards, these are pure
    microsoftisms and that's why they are implemented in nsDOMNSHTMLElement.
    offsetHeight on the root element is not supposed to reflect the heigth
    of the html element, it's supposed to reflect what MSIE replies when asked
    to give document.documentElement.offsetHeight. Here, our spec is
    (unfortunately) MSIE.

(b) with this change in, MSIE 6 and Mozilla behave **differently**. Launch MSIE
    and Mozilla, resize the two windows to be about the same size, and load
    the test case attached above; see the different heights.
    Tested with MSIE 6.0.2800.1106.xpsp2.021217-1051
            and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4)
                             Gecko/20040916 

The **whole** purpose of offsetHeight here is to have a microsoft-compatible
implementation. The change applied to Mozilla breaks that compatibility, as my
test proves it. I am therefore adding the regression keyword again. 

Comment 6

[Bernd]

re comment 4 isn't that layout on the weblog broken since ages, I can't remeber
to have seen it ever correctly. I always thought thats what you get when you use
table free layouts.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Why does the border stop on in-flow content's edge and not below the
> positioned elements ?

Because per the CSS 2.1 spec the root is just a block (or table) like any other.
 You wouldn't expect all blocks to stretch to include positioned content, would you?

> Don't the positioned elements belong to the document and change its height?

Sure, but "document height" and "root element height" are not the same thing,
again per CSS2.1.

> it's supposed to reflect what MSIE replies when asked to give
> document.documentElement.offsetHeight.

Which in IE is the height of the root element.  So no matter what we do here, as
long as our root element is a different height than IE's we CAN'T reflect what
IE does.

This is the usual IE-DOM issue -- when we have different layout, do we return
numbers corresponding to our layout (which is what people who are using the MS
functions to determine what the layout looks like want), or do we return numbers
that match IE's (which is what people making assumptions about layout matching
some other thing want).

If you have a proposal that won't break pages that actually want the size of the
root element, I'm all ears.

Comment 8

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #7)

> > it's supposed to reflect what MSIE replies when asked to give
> > document.documentElement.offsetHeight.
> 
> Which in IE is the height of the root element.  So no matter what we do here, as
> long as our root element is a different height than IE's we CAN'T reflect what
> IE does.

No. On the root element, MSIE seems to reply max(root's height, viewport's
height) so we don't do like IE.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> No. On the root element, MSIE seems to reply max(root's height, viewport's
> height)

You've verified this by putting a border on the root and seeing what size it is
in IE?  Because when I asked people to test this, it seems that the root's
height is in fact at least the viewport's height in IE at all times.

The basic question here is whether people asking for offset* on the root really
mean the root or the document.  I suspect they may well mean the latter, as you
claim...   If so, we'll need to account for the viewport size (and maybe the
overflow area?  Someone needs to test IE) when computing offset*. What about
client*?  scroll*?

Comment 10

[Bob Clary [:bc] (inactive)]

Attachment: testcase with borders/innerHTML

Comment 11

[Bob Clary [:bc] (inactive)]

Attachment: screenshot - mozilla 1.7.3

mozilla 1.7.3 html border and background fill view

Comment 12

[Bob Clary [:bc] (inactive)]

Attachment: screenshot - firefox trunk

firefox trunk - border wraps para, but background fills view. Doesn't seem
consistent to me.

Comment 13

[Bob Clary [:bc] (inactive)]

Attachment: screenshot - msie6 winxpsp2

msie6/winxpsp2 - border, background not visible

Comment 14

[Boris Zbarsky [:bzbarsky]]

> firefox trunk - border wraps para, but background fills view.

Please see the section of the CSS spec on backgrounds.  It talks about the root
element background at great length.

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 317046 has been marked as a duplicate of this bug. ***