Open
Bug 260498
Opened 20 years ago
Updated 2 years ago
nsGenericHTMLElement::offsetWidth returns different values for the root element
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
NEW
People
(Reporter: glazou, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(5 files)
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.
Reporter | ||
Comment 1•20 years ago
|
||
Comment 2•20 years ago
|
||
Daniel, you should ask for the bug to be blocking 1.8a4. If this is a regression then that keyword can be added.
Keywords: testcase
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.8a4?
Keywords: regression
Comment 3•20 years ago
|
||
> 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).
Keywords: regression
Reporter | ||
Comment 4•20 years ago
|
||
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?
Reporter | ||
Comment 5•20 years ago
|
||
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.
Keywords: regression
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•20 years ago
|
||
> 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.
Reporter | ||
Comment 8•20 years ago
|
||
(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•20 years ago
|
||
> 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*?
Updated•20 years ago
|
Flags: blocking1.8a4? → blocking1.8a4-
Comment 10•20 years ago
|
||
Comment 11•20 years ago
|
||
mozilla 1.7.3 html border and background fill view
Comment 12•20 years ago
|
||
firefox trunk - border wraps para, but background fills view. Doesn't seem consistent to me.
Comment 13•20 years ago
|
||
msie6/winxpsp2 - border, background not visible
Comment 14•20 years ago
|
||
> 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•19 years ago
|
||
*** Bug 317046 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Severity: critical → normal
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•