65548 - offsetWidth give back wrong value

Status: RESOLVED WORKSFORME

(Core :: DOM: CSS Object Model, defect, P4)

Description

[Jano]

<div id="container" style="width:100;height:100;">
	<div id="content2">
...
</div>
</div>

document.getElementById(content2).offsetWidth give back 100 (the width of the 
container div and not the real width of content2 div.
(offsetHeight works great)

Comment 1

[Jano]

Attachment: testcase for offsetWidth bug

Comment 2

[Keyser Sose]

Confirmed
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001011508


Marking NEW.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Going to attach the same testcase but cleaned up to be HTML 4.01 strict
compliant.  Also cleaned up CSS a bit and added borders around the <div>
elements so we can see what they look like.

Note that offsetWidth is correctly returning the width of the content area of
the content2 div.  The fact that the content overflows the content area does not
affect the width of the content area.

Setting qa to hixie to get his input, but I believe this is invalid -- Mozilla
is laying out the document exactly as specified by the stylesheet.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Cleaned up testcase

Comment 5

[Hixie (not reading bugmail)]

no idea what offsetWidth is, sounds like DOM0 evilness to me. => DOM Level 0.

Comment 6

[Johnny Stenback (:jst)]

Looks like the reason mozilla works differently here than IE does is that
mozilla does CSS correctly where IE fails and that's why the width of the div is
different in mozilla and IE. WONTFIX.

(Ian, element.offsetXXX are IE DOM extensions that we decided to support in
mozilla too.)

Comment 7

[Prashant Desale]

WONTFIX. Verified.

Comment 8

[Jano]

OK. But how can I get the REAL width of the element, if offsetWidth gives back 
the visible area's width ?? (In IE offsetWidth works like that).

(I have a scroll  script  (like at http://www.dream.hu but with horizontal 
scroll ability) where i should know the width of the content!!!)

Jano [e-mail]

Comment 9

[Johnny Stenback (:jst)]

Ian, is there some CSS tricks that could help Jano here?

Mark, is it possible (in mozills) to ask a fixed width frame for the width of
the widest line in the frame in the case where there's text in the frame that is
wider than the frame and the frame has overflow: visible; so that text flows
over the edges of the frame?

Reopening until we either find a workaround or find a fix for .offsetXXX,
setting milestone to mozilla1.0

Comment 10

[Hixie (not reading bugmail)]

jst: Well, the official solution is part of DOM3 Views, no?

Comment 11

[Johnny Stenback (:jst)]

Ian, if there would be a DOM Level 3 Views modules then yes, it would most
likely contain an API to get this kind of information, however, there's not
enough interest in the DOM WG to crate that module yet so it would be in DOM
Level 3 I'm afraid (we were the only ones pushing for it, nobody else had much
interest). So we need another solution in the mean time.

Comment 12

[elf_bb]

Attachment: a temporary solution

Comment 13

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 14

[basic]

with the workaround in attachment 57582 [details] does this bug still needs to be open?
This is due to the CSS2 box model being different from IE's, so it will be very
hard to emulate it I think.

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 138170 has been marked as a duplicate of this bug. ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

*** Bug 141732 has been marked as a duplicate of this bug. ***

Comment 17

[Gabriel Suchowolski]

I found tow work arround this problem... try this (el represents a div element)

- - - - - - - - - - - - - - - - - - WORK ARROUD 1
function getContentWidth(el){
     var tmp=el.style.overflow
     el.style.overflow='auto'
     var w=el.scrollWidth
     el.style.overflow=tmp
     return w
}
- - - - - - - - - - - - - - - - - - WORK ARROUD 2
function getContentWidth(el){
     var frag = document.createDocumentFragment(); 
     var p1=document.createElement('DIV')
     var p2=document.createElement('DIV')
     p2.style.visibility='hidden'
     p1.style.width=el.style.width
     p1.style.height=el.style.height
     p2.style.position='absolute'
     p1.style.position='relative'
     p1.innerHTML=el.innerHTML
     document.body.appendChild(p2)
     p2.appendChild(p1)
     var w=p1.offsetWidth
     document.body.removeChild(p2)
     return w
}
- - - - - - - - - - - - - - - - - - 

This tow work arround has one little problem I do not know how to solve... If 
you has the mozilla browser with cache option in "every time I view the page" 
and the DIV youw whant to take content width has images... the browser reload 
all the images. If this images has no width & height defined in the <IMG> tag 
the images shows with not the correct size during the reload so the content 
width is not correct returned.

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 56810 has been marked as a duplicate of this bug. ***

Comment 19

[Jan Ehrhardt]

A workaround for this bug seems to be to set the style.width of the outer box to
the offsetWidth of the inner box. Look at http://cgi.monitor.nl/temp/offset.htm
for an example.

This example shows two other things. The first one is that the rendering of the
outer box gets very weird if you move the box out of your window without setting
the style.width explicitly. IMHO, this is not the expected behaviour.

And the second one is that Mozilla expects the style.width of the outer box to
be set to the offsetwidth of the inner box (i.e. table). MSIE and Opera expect a
style.width = table.offsetWidth plus the (right and left) padding of the div.

Comment 20

[Boris Zbarsky [:bzbarsky]]

*** Bug 178965 has been marked as a duplicate of this bug. ***

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 178965 has been marked as a duplicate of this bug. ***

Comment 22

[p00r0]

Attachment: brower IFRAME.HTM and offsetWidth is wrong

Comment 23

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 108300 [details]
brower IFRAME.HTM and offsetWidth is wrong

This isn't a patch...

Comment 24

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 25

[Boris Zbarsky [:bzbarsky]]

*** Bug 214214 has been marked as a duplicate of this bug. ***

Comment 26

[Boris Zbarsky [:bzbarsky]]

Attachment: Another testcase

Comment 27

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #9)

> Mark, is it possible (in mozills) to ask a fixed width frame for the width of
> the widest line in the frame in the case where there's text in the frame that is
> wider than the frame and the frame has overflow: visible;

You can get the overflow rect. But that includes _all_ overflow.  In the
testcase I just posted, IE does not include the rel pos elements in its
offsetWidth calculation, while in Mozilla they are part of the overflow rect.

The real problem is that in both Mozilla and IE the offsetWidth is exactly equal
to the actual width.  It's just that the actual width is different, due to IE
bugs in its CSS implementation....

Comment 28

[Hixie (not reading bugmail)]

Shouldn't we mark this INVALID?

Comment 29

[Olivier Vit (just a reporter)]

Hi

renewing the discussion about this
offsetWidth value is wrong even for the document object

- go to http://www.quirksmode.org/viewport/experiments/body2.html
(strict mode is the only one to consider)
- resize your window to have both horizontal and vertical scroll bars
- get document.documentElement.offsetWidth and document.documentElement.clientWidth

Widths will always have the **same** value !!

while IE6 will adds the width of the scrollbar to clientWidth to return
offsetWidth, which makes much more sense to me, and makes it useful to have 2
different properties

testing with 1.7 post RC3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040613

Comment 30

[Mojmir Nebel]

offsetWidth is zero if element is outside area of container, while offsetHeight
is correct. The width always equals to visible part in containter area, so if
half of the element is in area and half is outside, offsetWidth is half of the
real width.

http://fog.jinak.cz/mozopbug.html

(Firefox 1.0.6/Win XP)

This bug is also in Opera, where offsetWidth is -1 when outside container.

Comment 31

[aaava]

offsetWidth is only giving wrong value, when a resize makes the browser window
*smaller* in width.  It works fine (Mozilla latest, and Firefox 1.06) when
*increasing* the resize width.  But it never decreases ala M$ &^*(^*&%(%& IE
does.  To have something work in M$ and NOT in Mozilla/Firefox, just ticks me
off! ;-)

As to the 'workaround'...the temporary solution, well, I looked at the code, and
all it seems to do is add an id to all the *other* tags, and then kludge a value
from this.  This just isn't an option, IMO.  Say I have a table, with four
columns (td's).  Three of the td's are assigned a fixed value.  The *content* td
contains a table with an id (say, 'storyTable').  If I put a percent width or no
width at all (so it can increase or decrease as the window size changes), the
getElementByID("storyTable").offsetWidth increases fine when I make the browser
window *wider*.  However, when I then resize the browser window to have a
smaller width, I get whatever was the MAXIMUM size of the element offsetWidth.

Does *anyone* have a valid workaround for this?  I have to be able to support
older browsers, and naming every td and table in a webpage and then working back
from this (assuming ALL the other elements ARE FIXED WIDTH...otherwise even that
would not work), is just way too messy a solution.  And suggestions greatly
appreciated.

Comment 32

[Bob McElrath]

In the mozilla 1.5 betas in XHTML mode, offsetWidth and offsetHeight are always zero.  Is this known?  Is this the right bug?

Comment 33

[Olivier Vit (just a reporter)]

Do you mean in Firefox 1.5 beta ?
Because Mozilla Suite is more likelly to be 1.8 beta, and then nobody would care about 1.5

Regards

Comment 34

[Bob McElrath]

Sorry yes, firefox 1.5 betas offsetWidth/offsetHeight are always zero on XHTML documents.

Comment 35

[Erik Arvidsson]

Attachment: This shows that offsetWidth/Height works in XHTML as well.

Bob: There is no difference between HTML and XHTML when it comes to offsetWidth/Height and this test case shows that. Could you attach your test case that you shows the problem?

Comment 36

[Bob McElrath]

It appears to be a timing issue.  Immediately after a node is added with appendChild, offsetWidth and offsetHeight are zero.  For some reason this does not happen with the same code with an HTML doctype.

Comment 37

[Anne (:annevk)]

I missed that Mike Taylor was hitting this recently, apologies for the noise.

Comment 38

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 39

[Emilio Cobos Álvarez (:emilio)]

Behavior here matches other browsers. Bug 1338448 seems specific to <embed> and is a fairly different bug.