If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

offsetLeft counts html border-left double

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Yves Goergen, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)

The most common method to detect an element's position on the page seems to be using IE's offsetLeft properties et al. This works nicely everywhere around, with one notable exception: If the html element has a border-left set, Firefox will count its width double to the offsetLeft value. See the attached test case for details.

The test case works fine for all combinations of padding-left, margin-left and border-left on the HTML element, for IE 7, Opera 9.6 and Firefox 3.0 (except for border-left, which this bug is about).

Reproducible: Always
(Reporter)

Comment 1

9 years ago
Created attachment 360133 [details]
Test case

You can replace the border-left style attribute by margin-left and padding-left to see that those work.
Can you retest with the latest trunk nightly build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Updated

9 years ago
Component: General → DOM: Core & HTML
Product: Firefox → Core
QA Contact: general → general
Is this a regression?
No, it doesn't seem like it. I see the bug also in Firefox 2.

This seems to have been fixed between 2008-09-07 and 2008-09-08:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-07+04%3A00%3A00&enddate=2008-09-08+09%3A00%3A00
I guess this was fixed by bug 243519.

So I'm marking this bug fixed, since this was fixed by bug 243519 and it doesn't make sense to backport the fix for that bug, since it's too risky and this isn't a regression.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Depends on: 243519
Resolution: --- → FIXED
(Reporter)

Comment 5

9 years ago
True, "Shiretoko" Firefox 3.1b3pre nightly of today behaves like any other tested browser, which I assume is the correct behaviour. Thank you.
You need to log in before you can comment on or make changes to this bug.