Closed Bug 67573 Opened 24 years ago Closed 23 years ago

offsetWidth and offsetHeight of dynamically created and inserted element returns 0

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: martin.honnen, Assigned: jst)

References

Details

(Keywords: dom2, Whiteboard: [HAVE FIX])

Attachments

(4 files)

Accessing the
  offsetWidth
property of a dynamically created DIV which has been inserted into the document
returns 0 while that of an identical statically created DIV is greater than 0.

<HTML>
<HEAD>

<SCRIPT>
function createDiv () {
  var div = document.createElement('DIV');
  div.id = 'div2';
  div.appendChild(document.createTextNode('Kibology'));
  document.body.appendChild(div);
  var r = '';
  r += 'div1.offsetWidth: ' + document.getElementById('div1').offsetWidth + '\n';
  r += 'div2.offsetWidth: ' + document.getElementById('div2').offsetWidth + '\n';
  alert(r);
}
</SCRIPT>
</HEAD>
<BODY ONLOAD="createDiv()">
<DIV ID="div1">Kibology</DIV>
</BODY>
</HTML>


I know that offsetWidth is not part of the W3C DOM but I think the same people
who write the DOM code for Mozilla added the offsetWidth property so I file it
on DOM level 2
Interesting.  Looks like the onload handler is completely executed before the
new element is really inserted into the document and the document reflows...  If
I create a separate function to put up the alerts and set up a timeout on it
(any timeout, even 1ms, will do), then I get the same value for both divs (that
is, the onload creates the divs and runs a setTimeout that will call the
function that puts up the alerts).

I am guessing that we are batching new element display to improve performance....
Attached patch Proposed fix.Splinter Review
The patch I just attached seems to fix the problem but I still need to verify
that it doesn't cause any other problems.

The problem is that when the presshell removes the dummy request from the
document loadgroup it does that while mIsReflowing is set to true and this
causes things in the onload haldler to not work as it should
(FlushPendingNotifications() doesn't flush since the presshell thinks it's not
safe to flush because mIsReflowing is true). My fix is to set mIsInReflow to
false while removing the dummy request from the loadgroup.

Nisheeth, does this make sense?
Status: NEW → ASSIGNED
OS: Windows 95 → All
Priority: -- → P3
Hardware: PC → All
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.8
Boris, the new element is completely inserted into the document in the onload
handler and the frame (the layout frame object) is created for it but the onload
handler fires with the presshell in a state where flushing pending reflows can't
be done, my patch fixes that by setting the presshell state to what it's IMO
supposed to be before firing the onload handler.
*** Bug 67630 has been marked as a duplicate of this bug. ***
Attached patch Proposed fix #2Splinter Review
Re-targetting for mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
*** Bug 69844 has been marked as a duplicate of this bug. ***
Summary: offsetWidth of dynamically created and inserted element returns 0 → offsetWidth and offsetHeight of dynamically created and inserted element returns 0
Keywords: dom2
Component: DOM Level 2 → DOM HTML
Attached patch Proposed fix #3Splinter Review
sr=waterson
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
VERIFIED that http://bugzilla.mozilla.org/showattachment.cgi?attach_id=24328 
works the same on IE as in Mozilla.
Status: RESOLVED → VERIFIED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: