Sub-category arrows appear when they shouldn't when using blockly_compressed.js
GoogleCodeExporter opened this issue · 6 comments
GoogleCodeExporter commented
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:
GoogleCodeExporter commented
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 commented
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 commented
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 commented
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 commented
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 commented
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