Open Bug 323664 Opened 14 years ago Updated 14 years ago

Retrieving offsetWidth destroys rendering


(Core :: Layout: Tables, defect)

Windows XP
Not set





(Reporter: micha, Unassigned)




User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

In view_detail.js there is the following method. The grid renders perfectly, however, if you uncomment the assignment the rendering is completely euhm.. foobar. This is very weird, but it happens. Looks like overflow on cells is being destroyed ?!

view_details.prototype.redraw = function(){
	//var offsetWidth = this.grid.rows[0].cells[0].element.firstChild.offsetWidth;

Reproducible: Always

Steps to Reproduce:
1. Download
2. Check result in browser
3. Now uncomment the line
4. Again check how the columns are misplaced 
5. Close you mouth, yes it is weird
I just did some additional testing. It seems any type of "delay" seems to cause invalid rendering of the cells. This rendering is not based on any timers whatsoever so I cannot really pinpoint if this is a JavaScript issue, or an rendering engine issue.

If you place an alert('something'); instead of the assignment the same problems occur, and the rendering goes wrong. 
I get "Error 404 occurred" on the grid.rar link.
But a minimal testcase would be more useful anyway.
document.body.offsetWidth forces Mozilla to layout the page, which indeed can cause a wrong layout, see:
Martijn, the url is faulty, sorry. It should be: 

Testcases are very hard to create, most issues come up in the most strange situations, and this is something I have never experienced before in other projects, ever. I don't think this is primarely an offsetWidth issue. I think it is related to internal timing within the browser, since an alert on that position also destroys rendering. None of the scripting relies on timing, they simply render the grid according to the array with the offsetWidth sizes. 

If assigning the offsetWidth stalls any correct future rendering, we might have a concurrency issue here? I have also tried using setTimeout to render with a pauze of 1000 milliseconds, with no change. Still, the sizes to render are correct, but the end result is far from that.

Opera en IE have no problem whatsoever.
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.