Opened 12 years ago

Closed 11 years ago

#5136 closed defect (duplicate)

race condition loading CSS / initializing widgets

Reported by: bill Owned by:
Priority: high Milestone: 1.3
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

Bug #5013 demonstrates a race condition with executing our JS initialization code before the CSS has finished downloading. Problem can happen on any browser although is most likely to happen on Safari since that's the fastest browser. Even after BorderLayout? widget is finished, things like TabContainer? still need all CSS loaded before they initialize, in order to compute the height/width of the tab labels correctly.

One possible solution is to implement a synchronous dojo.requireCSS() call, although that's complicated since it needs to deal @import statements somehow.

For now will add workaround code into mail demo but should fix for real.

Change History (7)

comment:1 Changed 12 years ago by James Burke

Is this a problem because of using @import? I have suspected it as being possibly asynchronous. If you use link tags I expect it not to be asynchronous.

I was hoping that only top level @import calls (in the actual HTML) may have been asyncrhonous, but maybe it is also a problem (or maybe the only problem) when the imports are inside a .css file?

If it is the nested imports, we could at least have a build option to replace the imports with the actual css rules (and fix the paths).

comment:2 Changed 12 years ago by bill

Ugh, I looked at this again and merely by moving the <style> tag (with the @import) above all the <script> tags, things work correctly (even without the timer). I wonder if that's a real fix or if it just narrows the odds on the race condition.

comment:3 Changed 12 years ago by guest

Hmm, well this will not happen for sure on IE6 or IE7. IE loads all CSS before rendering anything on the page. Once new CSS is found, a smarter browser would probably re-apply any operations (i.e. javascript) that accessed or modified a DOM node.

I think this might be an isolated issue with Safari and it sounds more like a bug / the the browsers job to this correctly.

Not an expert on this though :)

comment:4 Changed 11 years ago by bill

Milestone: 1.12.0

Well anyway, since there's a workaround and this isn't easy to fix, moving to 2.0

comment:5 Changed 11 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:7 Changed 11 years ago by bill

Resolution: duplicate
Status: newclosed

Closing as dup of #5402.

Note: See TracTickets for help on using tickets.