Sub-category arrows appear when they shouldn't when using blockly_compressed.js

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build Blockly with `python build.py`
2. Use blockly_compressed.js

What is the expected output? What do you see instead?
Expected: Arrows in tool box appear when a category has subcategories.
My output: Arrow pointing from left to right always being drawn on every 
category (even though without subcategories). See attached image.

What browser are you using?
Google Chrome Version 34.0.1847.132
Safari Version 6.1

Please provide any additional information below.
In the uncompressed version there is a blank `span` tag, in the compressed 
version the `span` is populated and has two `undefined` classes.

See also: https://groups.google.com/forum/#!topic/blockly/tZuA7dLI26E

Original issue reported on code.google.com by thomas.m...@gmail.com on 19 May 2014 at 10:54

Attachments:

• blockly-arrow-compressed.png
• blockly-arrow-uncompressed.png

[GoogleCodeExporter]

XML is:
<xml id="toolbox">
  <category name="Category 0">
  </category>

  <category name="Category 1">
    <category name="Inner 1">
    </category>
  </category>

  <category name="Category 2">
    <category name="Inner 2">
      <block type="controls_if"></block>
    </category>
  </category>

</xml>

Original comment by thomas.m...@gmail.com on 19 May 2014 at 10:57

[GoogleCodeExporter]

Confirmed.  Something must have changed in the Closure compiler service at 
Google.  This is likely a compression setting that's been changed to be 
slightly more aggressive.  An initial search has failed to locate the culprit.  
I'll keep searching.

Original comment by neil.fra...@gmail.com on 31 May 2014 at 3:58

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The problem is a significant API change in the Closure library (I'd earlier 
suspected the compiler, but it is innocent).  This bug lay undetected because 
Closure quietly moved from Google Code to Github, so we were pulling a year-old 
version.

r1721 updates the documentation so that uncompiled Blockly now pulls the latest 
Closure version.  This means that all Blockly modes now fail the same way.

Working on updating the TreeNode API...

Original comment by neil.fra...@gmail.com on 5 Jun 2014 at 4:55

[GoogleCodeExporter]

Fixed in r1724.  Thanks!
Sorry this took so long to resolve.  Both the primary Blockly contributors are 
out of the office, getting married.  To each other.  Sigh.

Original comment by neil.fra...@gmail.com on 5 Jun 2014 at 7:19

• Changed state: Fixed

[GoogleCodeExporter]

So we've recompiled with `python build.py` and the problem is still there. 
We've tried re-cloning closure (which needs to live near blockly for the 
compile).

Is there something else we need to do for in order to see this fix?

Original comment by thomas.m...@gmail.com on 13 Jun 2014 at 12:00

[GoogleCodeExporter]

It should work properly.  Here are two things to check:

1) Look at core/toolbox.js and see if it imports
  goog.require('goog.html.SafeHtml');
If not, then Blockly is out of date and you just need to svn update.

2) Look in closure-library-read-only/closure/goog/ui/tree/basenode.js and see 
if it also imports goog.html.SafeHtml.
If not, then delete the Closure directory and fetch it again.

If it still doesn't work, let me know and attach a copy of your 
blockly_compressed.js to this bug.  Thanks!

Original comment by neil.fra...@gmail.com on 13 Jun 2014 at 1:15