racecondition on mainWorkspace

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Checkout current(rev.639) blockly version
2. Run apps/maze demo with Firefox
3. When run without any breakpoints, it fails, when a breakpoint in the 
Maze.init() function in the maze.js is set, it works

What is the expected output? What do you see instead?
I expect the person and the target to be inside the maze.
Due to the racecondition, the person and the target stay in the upper left 
corner.

What browser are you using?
Firefox 18.0.2

Please provide any additional information below.
It is a race condition regarding the initialisation of Blockly.mainWorkspace, 
which is used on line 303 inside the maze.js, which reads 
"Blockly.Xml.domToWorkspace(Blockly.mainWorkspace, xml);", but 
Blockly.mainWorkspace is sometimes not initialized yet, and therefore a null 
value is given to domToWorkspace.

Original issue reported on code.google.com by Philipp...@gmail.com on 15 Feb 2013 at 6:28

[GoogleCodeExporter]

The problem has been introducted with version 630, version 629 did not have the 
problem.

Original comment by Philipp...@gmail.com on 15 Feb 2013 at 7:05

[GoogleCodeExporter]

Thanks for the bug report.  Blockly used to be synchronous but now it seems 
that it is not.  An issue is that Blockly.mainWorkspace is no longer set in 
Blockly.inject (inject.js, line 55).  It is now set in 
Blockly.SvgComponent.prototype.enterDocument (svg_component.js, line 180).  
Apparently the latter is triggered by an event, asynchronously.

scr, I could trivially add a window.setTimeout in each of the affected 
applications, but that's a hack that will get uglier over time.  What are your 
thought?

Original comment by neil.fra...@gmail.com on 17 Feb 2013 at 1:41

[GoogleCodeExporter]

Hmm, I think inject should return a goog.async.Deferred so that callers can do 
things after it is injected completely.  I think just returning the same css 
deferred, possibly calling branch() on it before returning.

Another thought I'd like your feedback on is the injection of the css in the 
first place, which was asynchronous, and had a race condition on getting the 
widths.  We could possibly unwind all of the assumptions of various 
enterDocument/init calls to let resize be called by various async activities 
(like loading css) but for now, changing affected apps to do

  Blockly.inject(...).addCallback(methodOrFunction, this /* if method */);

Would be the correct way, rather than slowing down one of the racers.

I'm not on the computer much this weekend, but I'll be sure to change the 
status if I get to starting this, otherwise take it from me if you have time.

Original comment by sheridan...@gmail.com on 18 Feb 2013 at 3:13

[GoogleCodeExporter]

This should no longer be an issue.

Original comment by neil.fra...@gmail.com on 11 Mar 2013 at 11:03

• Changed state: Fixed