306428 - incorrect offsetHeight

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Dmitry Sychov]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 

Mozilla reports incorrect offsetHeight for both links
on the following page:
http://www.accelware.com/browsers-bugs/offset_height_nn_bug.html

Ie 6 reports correct values

Reproducible: Always

Comment 1

[Gérard Talbot]

The markup code of the testcase is malformed. 
I get the expected results with

<p><font size="8"><a href="http://www.unitconversion.org">Huge Height Link
1</a></font></p>

<h1><a href="http://www.unitconversion.org">Huge Height Link 2</a></h1>

Note that size="8" in transitional DTD is not valid either since size only takes
an integer between 1 and 7.

If <font> is nested inside the link, then you get different values between IE 6
and Mozilla. This differential result is probably due to IE 6 buggy
implementation of overflow: visible.

Comment 2

[Dmitry Sychov]

I believe this is a bug, since offsetWidth remains correct in both cases.

> If <font> is nested inside the link

Yes, not only a font, but an <img> also, for example. Looks like every
element nested inside the link trashes offsetHeight, while leaving offsetWidth 
_correct_.

Oh, I'am sure this is a bug:

Opera 7
1 case - INCORRECT! (zero height)
2 case - CORRECT as IE

Opera 8
1 case - CORRECT as IE!
2 case - CORRECT as IE

Comment 3

[Martijn Wargers (dead)]

Attachment: Testcase

The first link in this testcase is probably the same as bug 258531.
But I think the offsetHeight in the second link is wrong. It should be much
higher. It seems as if the offsetHeight is only computed for the box it
encounters. IE6 returns 262 as offsetHeight for the second link (57 for the
first link).

Comment 4

[Boris Zbarsky [:bzbarsky]]

So we _could_ "fix" offsetHeight to deal with {ib} splits.  The question is whether that's really what IE does...

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Definitely seems like that is what IE does. In the IE DOM the <h1> is a child of the <a>.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So we'd need to replace the GetNextInFlow() call in nsGenericHTMLElement::GetOffsetRect with something more like GetNifOrSpecialSibling() (which currently lives in nsCSSFrameConstructor.cpp).

What's the offsetWidth IE reports in this case?  We'd end up reporting the width of the parent block (so the body) if we did this.

Comment 7

[José Jeria]

Attachment: Testcase2

Firefox:
1 link: offsetHeight: 21, offsetWidth: 389
2 link: offsetHeight: 41, offsetWidth: 182

IE 6:
1 link: offsetHeight: 57, offsetWidth: 389
2 link: offsetHeight: 262, offsetWidth: 198

Comment 8

[José Jeria]

Attachment: Screenshot

Don't know if necessary, but anyway...

Comment 9

[Boris Zbarsky [:bzbarsky]]

What happens in IE if you don't set a width on the div in that testcase?  What happens if the div has no width style and the <h1> contains no text?

Comment 10

[Martijn Wargers (dead)]

Attachment: testcase3, without width for div

With IE6, I get for this (without a style width set for the surrounding div):
2 link: offsetHeight: 114, offsetWidth: 622

Comment 11

[Martijn Wargers (dead)]

Attachment: testcase4, without style width and with empty h1

This gives the following value for IE6:
2 link: offsetHeight: 59, offsetWidth: 622

Comment 12

[Boris Zbarsky [:bzbarsky]]

I assume 622 is the width of your browser window, right?

In that case, we might want to move the special sibling stuff to nsLayoutUtils so we can use it in nsGenericHTMLElement.  I guess I can do it when I get back if someone reminds me...

Comment 13

[Martijn Wargers (dead)]

(In reply to comment #12)
> I assume 622 is the width of your browser window, right?
No, it's the width of the second link, caused by the second line of the link.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So the offsetWidth of the link is narrower than the offsetWidth of the block child of the link?

Comment 15

[Martijn Wargers (dead)]

Yes.

Comment 16

[Boris Zbarsky [:bzbarsky]]

In that case just adding up the sizes of the special siblings is no going to work.  Sounds like we need a clear spec of what IE actually does -- eg it counts the block child in the height, but not in the width... how come?

Comment 17

[Martijn Wargers (dead)]

Apparently, IE6 looks in horizontal direction only for the width of the widest text line or something like that.

Comment 18

[Boris Zbarsky [:bzbarsky]]

If we really care about something like that we _might_ be able to get partway there with GetMinWidth() and GetPrefWidth().  Maybe...

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think we need to blindly follow IE whatever it does. It needs to be something that we can document and that either is

A. Useful to a lot of developers
or
B. Breaks sites that affect a lot of users.

Comment 20

[Anne (:annevk)]

What Internet Explorer does depends on hasLayout: http://www.satzansatz.de/cssd/onhavinglayout.html I would very much encourage not to follow that.

I'm trying to standardize these and other layout attributes in: http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8

Comment 22

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.