Last Comment Bug 480030 - getBoundingClientRect appears to be offset
: getBoundingClientRect appears to be offset
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://www.sprymedia.co.uk/media/misc...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-24 13:44 PST by Allan Jardine
Modified: 2010-08-29 07:10 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Allan Jardine 2009-02-24 13:44:15 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-gb) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre

In the text example, I've cloned a node and set the clone to be positioned absolute - with the position based upon getBoundingClientRect(). I would have expected the cloned node to exactly overlay the original - but it appears to have an offset. If you remove one of the <br>s the error is smaller, with noether of the <br>s then the offset appears to be as small as one px.

Tested and fully reproducible in:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6


Reproducible: Always

Steps to Reproduce:
1. Just load my example page
2.
3.
Actual Results:  
There is an offset on the cloned node.

Expected Results:  
There shouldn't be an offset.
Comment 1 User image Robert Longson 2009-02-24 15:13:25 PST
If you set style="text-rendering:geometricPrecision" on all the text does that fix it.
Comment 2 User image Allan Jardine 2009-02-24 23:41:01 PST
I'm afraid not. If I add style statements for the body, html, p and span tags (the only rendering elements I've really used) with text-rendering:geometricPrecision, then the offset is still apparent.
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2010-08-29 07:09:38 PDT
This is the right behavior.  While the two <span>s have the same vertical position, one is a block while the other is an inline.  And the position of the block doesn't match the position of the parent block of the inline.  Which means that the vertical-align calculations are performed with different baselines.  And in particular, for any line-height that's different from the font-size you will get an offset because the leadings are being added in different places (for the inline above and below the inline itself and thus affecting its position, while for the positioned text inside the positioned block).  In effect, any nonzero leading is double-counted in the positioned block.

Since normal line height is not equal to the font size, you get the observed behavior.

Setting line-height to 1em on the positioned element should make the layout what you want.

It's odd that Webkit and Opera seem to do something different here, though...
Comment 4 User image Boris Zbarsky [:bz] (still a bit busy) 2010-08-29 07:10:47 PDT
Though that may just be an effect of them rounding their getBoundingClientRect, at least for webkit.

Note You need to log in before you can comment on or make changes to this bug.