Open Bug 940272 Opened 12 years ago Updated 3 years ago

offsetTop incorrectly reported if previous sibling is positioned absolute

Categories

(Core :: Layout: Text and Fonts, defect, P5)

Product:
Core
Component:
Layout: Text and Fonts
Version:
25 Branch
Type:
defect

Tracking

()

People

(Reporter: andy, Unassigned)

Details

(Keywords: testcase, Whiteboard: invalid?)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131025151332 Steps to reproduce: Please see http://www.milonic.com/bugreports/mozbug8.html for sample code detailing the problem. Actual results: offsetTop for the link returns an incorrect value. Expected results: offsetTop for the link should return the same offsetTop of the span. This works on all other browsers except for Firefox. Please note that if I add a border for the link, the offsetTop value returned is correctly. Also, changing the link's display value to 'inline-block' returns offsetTop correctly.
Thanks for the report! Do you happen know if this worked correctly on previous versions of Firefox? (ie is a regression)
Component: Untriaged → DOM: CSS Object Model
Keywords: testcase
Product: Firefox → Core
This also seems to be incorrect on current Nightly on OS X, so marking all/all.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: offsetTop incorrectly reported if previous object is positioned absolute → offsetTop incorrectly reported if previous sibling is positioned absolute
Works for me on Linux (I see 10px and 10px for both the a and the span).
(In reply to David Baron [:dbaron] (needinfo? me) (UTC+8) from comment #3) > Works for me on Linux (I see 10px and 10px for both the a and the span). Yeah, I just checked on Linux, works for me there, too. I wonder why this is different on OS X and Windows then... David, is this the right component for this bug or should it go somewhere else?
Flags: needinfo?(dbaron)
(In reply to :Gijs Kruitbosch from comment #4) > (In reply to David Baron [:dbaron] (needinfo? me) (UTC+8) from comment #3) > > Works for me on Linux (I see 10px and 10px for both the a and the span). > > Yeah, I just checked on Linux, works for me there, too. I wonder why this is > different on OS X and Windows then... David, is this the right component for > this bug or should it go somewhere else? If you add a border in Linux and then click for result, my links offsetTop value becomes 9px - I think this is still wrong. It's different to other systems but still wrong.
Not sure if this is related to this bug but I found something else that might be of interest. Encasing the span and link inside a div that has position:relative with overflow:auto and also a border it changes things even more. In Chrome and IE, the offsets returned are 0px but in Firefox they are related to the border dimensions, the spans top and left offsets returned are related to the width of the containers border. Here's another demo: http://www.milonic.com/bugreports/mozbug9.html This appears to be the same in Firefox for Linux, OSX and Windows.
Comment 6 seems to be about bug 850684, for what it's worth. Looking at the original testcase, the absolute positioning of the previous sibling, and indeed the existence of that previous sibling, seem to have nothing to do with what's going on. Furthermore, the value being reported is in fact correct in the sense that it matches the actual layout. At least on Mac. Here's a minimal testcase that on my Mac shows a red strip above the blue inline, and a corresponding offsetTop of 12: <!DOCTYPE html> <body style="margin: 0"> <div style="margin: 10px; background: red;"> <span style="background:blue; color: white" onclick="alert(this.offsetTop); return false"> Is there a red strip above me? Click to see my offsetTop </a> </div> </body> It's not clear to me exactly why that red strip above (and below!) the inline is there, given the lack of explicit font styles in the testcase. David?
Normal line-height can include leading that's not part of the extents of the font, and many fonts have metrics that suggest such leading.
Flags: needinfo?(dbaron)
So I take it the "incorrect" value is pretty close to 10px, just a little larger?
Component: DOM: CSS Object Model → Layout: Text
That's what I observe at least, yes. That might also explain the OS-dependence: it's actually a default-font dependence.
Agreed, after a little more digging it is indeed a font issue. Is this still considered a bug or not? I get different values on all other browsers, could it be a number rounding issue?
It seems to me that the added leading is intentional: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsHTMLReflowState.cpp#2367 with the enum values defined here: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsHTMLReflowState.cpp#42 This pref controls which is used: browser.display.normal_lineheight_calc_control default is 2 (eCompensateLeading) (you need to restart Firefox for a change to take effect) I tried 0 and 1, they did not add any leading in the comment 7 test (on OSX).
Priority: -- → P5
Whiteboard: invalid?
Andy, adding line-height:1 in the stylesheet might work as a workaround for you.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.