If an element has overflow set to hidden or auto/scroll and the content of the element overflows there should be a way to get the size of the content. In NN4 this could be achieved with layerObj.document.height (and width) and in IE4+ this can be done using element.scrollHeight (and scrollWidth). In Mozilla this can not be done and it is really limiting Mozilla as a platform for creating DHTML Applications

Wouldn't this work: Enclose the content of the scrolling container in a block element with no size constraints, and use getComputedStyle to get its dimensions: <div id="container" style="width:100px;height:100px;overflow:scroll;"> <div id="content">content here can be any height</div> </div> ... getComputedStyle(document.getElementById("content"),null).getPropertyValue("height"); Yes, it does work, I just tested it. If something this simple works, then I wouldn't consider it as something "limiting Mozilla as a platform for creating DHTML Applications". No need to add proprietary properties when you can accomplish something with existing standards.

Adding an extra element is not a viable solution. The solution is a hack and it changes the content model. This might not be possible in all cases and it will need extra reflows (reflows are slow) if done at runtime.

This bug is related to other scroll models bugs such as #62536 and #80744. There are probably more of these but these are the ones I know about

Ah, I see now, this makes sense in the context of a comprehensive scroll model, which I didn't know you were talking about. I thought you were just looking for a way to get the dimensions of content within an overflowed container, my apologies. I don't believe however that the severity of this is critical, especially as there are workarounds or "hacks" as you call them. >>If an element has overflow set to hidden or auto/scroll and the content of >>the element overflows there should be a way to get the size of the content. ...or overflow:visible for that matter. Overflow is overflow. Basically we need a scroll model (more accurately an overflow model) for any overflowed elements. How is scrolling handled in XUL? Could it be applied to HTML/XML elements also?

True, but this is a large change that won't make it in any time soon.

Aren't the values already available behind the scenes? If not then how does the scroll bars find out their max, value and extent? To me it seems like all that is needed is to add an interface that maps these properties to XPCDOM properties. I've also tried looking for the dom nodes used to render the scroll bars on an element by looking up the anonymous nodes on the element but the XUL scroll bars did not show up.

Isn't this a dupe of bug 62536?

This is a duplicate. Since I reported this I'll mark this as a dup. *** This bug has been marked as a duplicate of 62536 ***

Try with this ... it is working with my API if(is.ie) domLayer.prototype.contentW=function(){ var tmp=this.css.width; this.css.width ='auto'; var w=this.elm.offsetWidth||0; this.css.width=tmp; return w; } else domLayer.prototype.contentW=function(){ var tmp=this.css.overflow; this.css.overflow='auto'; var w=this.elm.scrollWidth; this.css.overflow=tmp; return w; } domLayer.prototype.contentH=function(){ var tmp=this.css.height; this.css.height='auto'; var h=this.elm.offsetHeight||0; this.css.height=tmp; return h; } Gabriel Suchowolski work. www.microbians.com member of. www.chromeless.org www.domestika.org

That works in a few cases but not all. For example it will give wrong results when there are nesting elements that clip the content. Test case coming up.

This test case shows that Gabriel Suchowolski's hack is not sufficient (comment 9).