Ticket #5136 (closed defect: duplicate)

Opened 13 months ago

Last modified 2 days ago

race condition loading CSS / initializing widgets

Reported by: bill Owned by:
Priority: normal Milestone: 1.3
Component: Dijit Version: 0.9
Severity: normal Keywords:
Cc:

Description (last modified by bill) (diff)

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

Changed 12 months ago by jburke

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).

Changed 12 months 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.

Changed 12 months 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 :)

Changed 12 months ago by bill

  • milestone changed from 1.1 to 2.0

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

Changed 9 months ago by alex

  • milestone changed from 2.0 to 1.3

Milestone 2.0 deleted

Changed 7 months ago by bill

  • description modified (diff)

Changed 2 days ago by bill

  • status changed from new to closed
  • resolution set to duplicate

Closing as dup of #5402.

Note: See TracTickets for help on using tickets.