All users were logged out of Bugzilla on October 13th, 2018

offsetWidth and getComputedStyle give wrong values for div nested in div of lesser width

RESOLVED INVALID

Status

()

RESOLVED INVALID
16 years ago
16 years ago

People

(Reporter: scottk, Assigned: jst)

Tracking

({regression, testcase})

Trunk
x86
Linux
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021230
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021230

If div(x) is nested within div(y) that has width = 'z' and overflow:hidden, both
offsetWidth and getComputedStyle.getPropertyValue("width") for div(x) return the
value of 'z', which is usually not correct.

This appears to have broken between linux trunk builds 2002121221 and
2002121321.  1.3a works correctly as well.

Reproducible: Always

Steps to Reproduce:
1.Load the test case on a current build, and 1.3a
2.compare the values.
3.

Actual Results:  
wrong offsetWidth is computed.

Expected Results:  
should produce the correct offsetWidth
(Reporter)

Comment 1

16 years ago
Created attachment 110367 [details]
test case that shows the wrong offsetWidth
(Reporter)

Comment 2

16 years ago
adding regression and testcase keywords
Keywords: regression, testcase

Comment 3

16 years ago
I get both values 979 with Gecko/20021212 under WinXP, it look as a correct
values. Maybe OS specific trouble?
caillon, you're doing getComputedStyle now, right?
(Reporter)

Comment 5

16 years ago
Ruslan, 20021212 is the last build that does give me the correct values.  Could
you test this again on WinXP with a current build?

Comment 6

16 years ago
Got 750px, 750 on WinXP on Gecko/20021230. So OS --> ALL?
The computed width changed because the actual width of the <div> changed.  put 
a border on the div to see this (general good practice when reporting bugs in 
computed style is to check whether the computed style matches the style you're 
seeing...)  The <div> width changed because the old value was completely 
wrong.  See bug 180711 (the fix for that is what you're detecting).

This is not a bug.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 8

16 years ago
OK, then I guess I coded around an 'incorrect' value that was exactly what I
needed!  So the question now is how using the DOM I can get what the 'old'
offsetWidth was? What I need is the 'width' of the inner div as if it were
rendered without being constrained by the outer cliping div.

Also wasn't offsetWidth added for IE compatibility?  If so, it is no longer
compatible, as IE 6 gives the 'incorrect' value.

I no bugzilla is not a help forum but it took me several days to find the now
non-functioning 'solution' way back when we were on Mozilla 0.8, and it has
worked great until now.
You can't do what you want using a div in Mozilla right now (you could using a 
table, which does not allow the content to overflow...)

See bug 65548 on the handling of overflow with offsetWidth
You need to log in before you can comment on or make changes to this bug.