As a result, all variables in Blockly follows the lead of App Inventor by making all variables global.

Consider revising to

As a result, all variables in Blockly, following the lead of App Inventor, makes all variables global.

https://developers.google.com/blockly/about/language

Dear developers,

We have found another bug (similar to #12) and produced a test-case to demonstrate it.

Please navigate to http://ens-lg4.github.io/blockly_bug_report/ to reproduce
and to https://github.com/ens-lg4/blockly_bug_report to see the test-case files involved.

Many thanks in advance for your attention.

when i finished editing a text block and click confirm,the new text is set.And then no matter where I touch on the screen,the keyboard shows up again.I use UIWebview to load a local html.
exactly the the same issue described in this link:https://code.google.com/p/blockly/issues/detail?id=169.

It would be useful to have a more fully fleshed out event API. At the moment anything interacting with Blockly has to listen to changes on the workspace as a whole and then attempt to inspect to see if values of interest have changed. While this is feasible, it is cumbersome, particularly considering how frequently the workspace change event gets fired.

At a first pass just firing 'change' events on individual blocks when something happens to them would be helpful, but it might perhaps also be helpful to fire 'value_change', 'unplug', and other values. These could be triggered from within the relevant methods that already exist in the Blocks.

Happy to try to implement this if it is something that is desirable, and this design seems appropriate.

I've notice that the code demo does not work in IE11 in the latest head (1c39a63 at the time of writing).

The problem arises in xml.js file when it is trying to parse the toolbox xml (https://github.com/google/blockly/blob/master/core/xml.js#L199). I'm not quite sure if i'll have the time in the inmediate future to look into it to submit a pull request, so I though I should post it here in case somebody else can do that.

Using the "graph" demo (with PR #25 applied) on iOS 8 gives strange results with detecting whether or not something was dropped over the trashcan. When zoomed out, I'm unable to throw things away. When zoomed in, any time I move a block it gets deleted.

when dragging a procedure_def block into workspace, in the toolbox, the field that contains "with:" of procedure_call block is rendered.

Dear Neil,

Could you please modify the code of Blockly.Connection.prototype.highlight (from connection.js)
so that it would use the constants Blockly.BlockSvg.NOTCH_PATH_LEFT and Blockly.BlockSvg.NOTCH_PATH_RIGHT defined in block_svg.js instead of redefining both paths again. It would make it possible for Blockly users to change the shape of the inter-statement notch without touching business code.

Many thanks in advance!

I don't know if this happens with other blocks as well, but for the "colour with" block I've found a weird snap when the block is close to the first input. If we try to drop a block as shown in this screenshot:

It ends up snapping to the grid right below the one expected. You can see it animate towards the top position, but it intermediately moves to the one square below:

This does not happen with the current version in https://blockly-demo.appspot.com/static/demos/code/index.html , so probably something to do with the latest commits in master.

How to reproduce: switch on RTL mode on injection, do not create a toolbox, but pre-place some blocks on the workspace. Then drag any block and drop it back onto the workspace. The block itself and the associated cluster of its children will disappear with animation as if dropped into the trashcan.

For some reason the method Blockly.Workspace.prototype.isDeleteArea returns true in the middle of the workspace. It probably shouldn't?

When I input too many words in one text, the block will be too long. How could I make it start from a newline?

now：
public void test() { System.out.println("Hello blockly"); }

hope：
public void test() {
System.out.println("Hello blockly");
}

Was checked with the demo ....tmp/google-blockly-610565e/demos/code/index.html

• from the 'Functions' menu add a function block into the editor (e.g. name it 'testfunc')
• for the function block define use of a parameter - click at the Star icon and attach 'input name' block to the main block (give it a name: arg)
• click at the Star icon to hide the context menu of the created function block
• try using a block for calling the function: from the 'Functions' menu select the block 'testfunc with arg'.
  The calling block will be displayed in the editor just as 'testfunc' without a possiblity to specify its argument

This used to work, but doesn't now (I last updated blockly ~ a week ago).

If you define a procedure, the flyout correctly shows the labels of the arguments in the call block like this:

However, if you change the arguments (change the names, add an argument, whatever) the labels for those arguments disappear in the calling block:

Dear developers,

We have found a bug and produced a test-case to demonstrate it (a picture is worth 2^10 words).

Please navigate to http://ens-lg4.github.io/blockly_bug_report/ to reproduce
and to https://github.com/ens-lg4/blockly_bug_report to see the test-case files involved.

Many thanks in advance for your attention.

Since closure is moving to github, there's no default closure-library-read-only path anymore. we could modify build.py to support both of them.

Dear developers,

We have found another example of counter-intuitive behaviour ((possibly a bug?) similar to #12 and #15) related to binding/repelling rules, and produced a test-case to demonstrate it.

Please navigate to http://ens-lg4.github.io/blockly_bug_report/ to reproduce
and to https://github.com/ens-lg4/blockly_bug_report to see the test-case files involved.

This example deals with vertical binding of statements. The same effect happens when trying to bind inputs horizontally.

Many thanks in advance for your attention.

When move a block or panning the workspace the page is scrolled. I've find the issue in Blockly page.

Android version: 4.4.2
Firefox version: 36.0.4

This may or may not be a bug. The Blockly.Connection.prototype.hideAll function doesn't actually hide the connections (setting this.hidden_ = true;). The corresponding unhideAll function does set this.hidden_ = false;.

I am doing some weird type checking with my app (depending on the nextStatement's block type, I hide and unhide inputs on some blocks), and I was getting a glitch where I'd see a highlighted connection path for hidden inputs (although only after I'd dragged around the parent block after a hide - as if the hidden input connection got repopulated into the connection database during the drag? I don't know this, I didn't track down why it only happened after a move). I could even connect a block into the hidden input! I fixed my glitch by adding
this.hidden_ = true;
into the hideAll function (called from the input.setVisible function).

There may have been a good reason not to put this statement in? - if so, please respond to this so I can figure out a better way to fix my glitch. Thanks.

when write a large comment and try to scroll with arrow keys, the scroll don't work properly and cause a little displacement of the field. This works well on firefox.

After clicking a mutator of a 'list_with' block the console shows:
Uncaught TypeError: Cannot read property 'textContent' of undefined

Hi

I am using resizable blockly for a cross device visual IDE. Things work great on most devices but I'm having problems with Chrome and Safari on iOS.

On load, blockly appears as expected but as soon as I open a toolbox menu the blocklySvg element and several of its children go into an infinite height resize. I noticed that https://developers.google.com/blockly/ seems to have the same problem.

I assume this is an event loop issue somewhere deep in one of the many Google dependencies but I can't get to the bottom of it :(

I am unable to drag blocks in the latest version of blockly if using touch input. I have tried this using the several of the demos on:

• Android: chrome allows to drop blocks from toolbox with a single touch, but there is no dragging, android browser does not do anything with the toolbox
• iOS7 on iPad: same results as Android chrome with safary and iOS chrome
• Windows 8 laptop with touch screen: same behaviour in chrome and opera, IE11 will kind of choppily react to touch dragging, firefox works fine

If using Blockly in a modal created by jquery, and bootstrap; there are two artifacts which are hard to debug.

Maybe this issue should be placed into a special chapter in blockly documentation for Bootstrap integration fixes.

Issue 1. all drop down appears behind the modal.
Solution 1 : Just update the page css

.blocklyWidgetDiv {
    z-index: 9999 !important;
}

Issue 2 : all input fileds (numbers, strings,...) are not working (never focused)
Solution 2 : when the modal is shown, apply this fix

Boostrap 3

$('div#modal-blockly').on("shown.bs.modal", function () {
   //fix input field
   $(document).off('focusin.modal');
}

Boostrap 2

$('div#modal-blockly').on("shown", function () {
   //fix input field
   $(document).off('focusin.modal');
}

Hi Neil.
When i create a custom block with a text input with Blockly.FieldTextInput, should be a way to disable spell checking in case of not need it.

Is there a reason that we can only change the HSV hue value ?
Otherwise I could make a pull request with a setHSV function :)

btw, I checked the repository of http://code.org/ https://github.com/code-dot-org/code-dot-org/tree/staging/blockly-core they have done some nice upgrades

Please tag a release

Steps to repro:

1. Open a blockly demo in OS X Safari
2. Click and drag on a block

Expected: usual hand closed cursor
Actual: distorted image (see below)

Screencast: http://screencast.com/t/eWDuxYxW

The example below shows that [2 - [3+4]] is handled differently to [2 * [3+4]].

Blocks should act as parentheses -- as the [2 * [3 + 4]] example and the discussion in https://developers.google.com/blockly/custom-blocks/operator-precedence indicates.

The interpretation of [2 - [3+4]] as (2 - 3 + 4) = 3 instead of (2 - (3+4)) = -5 is plainly inconsistent and extremely unfortunate if blockly is to be taken seriously as an educational application.

My blockly is less than a week old.

Bring out a procedure and a call block and it looks great:

If you then collapse and expand the call block, it gets a "with" field (gets it while collapsed too, I didn't make a screenshot):

When trying to expand the Field flyout, the browser throws
TypeError: this.textElement_ is undefined blockly_compressed.js:1106:133

Using the uncompressed.js the error is
TypeError: this.textElement_ is undefined field_angle.js:217:4

Stack trace:
Blockly.FieldAngle.setText (field_angle.js:217)
Blockly.Field (field.js:43)
Blockly.FieldTextInput (field_textinput.js:46)
Blockly.FieldAngle (field_angle.js:63)
Blockly.Blocks.field_angle.init (blocks.js:231)
Blockly.Block.fill (block.js:128)
Blockly.Block.initialize (block.js:85)
Blockly.Block.obtain (block.js:71)
Blockly.Xml.domToBlock (xml.js:264)
Blockly.Flyout.show (flyout.js:364)
Blockly.Toolbox.TreeControl.setSelectedItem (toolbox.js:291)
goog.ui.tree.BaseNode.select (basenode.js:590)
Blockly.Toolbox.TreeNode.onMouseDown (toolbox.js:346)
goog.ui.tree.TreeControl.handleMouseEvent_ (treecontrol.js:539)
goog.events.fireListener (events.js:727)
goog.events.handleBrowserEvent_ (events.js:851)
(anonymous function) (events.js:276)

Something seems to have changed in the closure compiler service on 3/9 that prevents blockly from building the compressed files. I have successfully built them prior to this date (on 3/8).

Steps to reproduce:
Clone blockly
Download the closure zip file from the link provided by build.py
Run build.py

Console output:
...
SUCCESS: msg/js/zh-hant.js
SUCCESS: blockly_uncompressed.js
FATAL ERROR
required "goog.html.SafeHtml" namespace never provided
core/connection.js at line 33:
goog.require('goog.html.SafeHtml');

Hi, this project seems great and I am evaluating it for use in a project. I've noticed that code lives both here on Github as well as in Google Code. It would be preferable for me to use code from Github, as it is in Git and therefore much easier to work with and contribute to. Is there parity between this repo and the Google Code repo? If not, which is the canonical repo going forward?

Thanks for this awesome tool!

I noticed that realtime wasn't working in tests/playground.html nor in demos/realtime/index.html. I have included the steps to reproduce. Let me know you need more information or I need to configure something else.

OS: Ubuntu 14.10 (64-bit)
Google Chrome: Version 41.0.2272.101 (64-bit)
Google Closure: 848686a4791374beaa99478cdf37d95deb2752e1
Commit: 706080c
Last known working commit: 8d53788

Steps to reproduce:

1. Go to /blockly/tests/playground.html. In start() set realtime to true and change clientId to valid client id.
2. Run in localhost or appengine. I tested both. I use WebStorm for running locally.
3. Login in your google account and agree.
4. After the workspace is reloaded, click on any block in the workspace and no flyout menu will appear. I included a screenshot of the javascript console.

If I have an "if" mutator with a couple of statements in it like so:

and then take away the else statement via the mutator dialog, I get (as expected):

If I then re-add the else statement to the if block, the expanded mutator doesn't bump away the unconnected second statement, making it look like there is a connection when there isn't one.

While trying to update the JSON import/export I was trying to build the demos/code application. with the latest release the instructions for building the apps using soy are broken. Soy is located in the plane demo however there seems to be none of the soy templates need to actually build "code".

Andrew

I'm not 100% sure how to replicate this issue, I can currently trigger it in the https://blockly-demo.appspot.com/static/demos/code/index.html demo and the latest master with Chrome and Firefox. It is more likely to happen when there are no other block in the workspace and I have not yet dragged the workspace.

When a new block is clicked from the toolbox flyout it moves the entire workspace a few pixels to the right and bottom. This workspace movement happens before I release the click. It will continuously happen until I drag the workspace around to move the current blocks to the side.

Please let me know if you need a better explanation or a quick video.

Sometimes Blockly.Named.equal called with null or undefined arguments.

This patch fix this issue:
Blockly.Names.equals = function(name1, name2) {

• return name1.toLowerCase() == name2.toLowerCase();
• return (name1 || '').toLowerCase() == (name2 || '').toLowerCase();
  };

Dear developers,

Some blockly diagrams are large enough and would benefit from scrollbars around the workspace.
However at the moment it is only possible to have scrollbars if the toolbox is also using categories.

Using categories becomes reasonable if you have very many different blocks, otherwise it adds unnecessary complexity (the user not being able to see all the blocks, extra clicks, etc).

We would like to build relatively large diagrams, be able to scroll them, but avoid using categories as our choice of different blocks is small.
Could you please de-couple the scrollbars from categories?

Many thanks in advance!

As mentioned in the mailing list by Marcus F, the following page should probably list the prython version (2) needed to run the build.py script.

https://developers.google.com/blockly/hacking/building

Hi,

When blocks are being drag and a warning is added to any of the blocks (therefore adding the warning icon), the blocks svg misaligns until they are reattached one by one.

As demo I have recorded this quick video of my fork, as I was not quite sure how to replicate the problem with normal blockly:
https://www.youtube.com/watch?v=csbsCaaR_So

Hey, I'm not sure if this has been reported--I haven't found any mention of it on the internet, so I'm wondering if I'm going a little insane, to be honest--but field editors don't seem to work on iOS 8. Even on Blockly's official demos, like the one at the top of https://developers.google.com/blockly/.

Over the past several weeks, I have tried this on two iOS 8 devices with the latest updates installed: an iPhone 5 and an iPad Air. Both seem to exhibit the same behavior: any editable field, such as field dropdowns and colour fields, can be "highlighted" (i.e. have a solid white border drawn around them when tapped) but nothing else happens: no popup or window.prompt is shown.

I've found that removing the following conditional from Blockly.Field.prototype.onMouseUp_ in core/field.js fixes this for me:

  if ((goog.userAgent.IPHONE || goog.userAgent.IPAD) &&
      e.layerX !== 0 && e.layerY !== 0) {
    // iOS spawns a bogus event on the next touch after a 'prompt()' edit.
    // Unlike the real events, these have a layerX and layerY set.
    return;

My only guess is that at some point Safari on iOS actually started setting layerX and layerY for their real events, which meant that all real events were being interpreted as bogus events, thereby being eaten up by the above code. But I am also extremely unfamiliar with how Blockly's UI works, so it's just a guess. I also have no idea if removing the above conditional causes some kind of regression, though in my brief testing (including experimenting with fields that cause a prompt() edit) does not seem to indicate it.

If my thinking is right, though, I suspect this does cause regressions on iOS devices that still have old versions of Safari/iOS, so perhaps a more robust fix would be to just add an extra conditional that looks at the user agent's version of Safari/iOS and only no-ops if it's below a certain version. I'm not sure how many iOS devices "in the wild" are still on this old version, though, and the task of figuring out which Safari/iOS version "broke" Blockly's field editors still needs to be done.

In any case, if any of my solutions described above seem like a reasonable fix, I'm happy to submit a formal PR.

There is a grammatical sentence used in README.md file.
Attached document is a snapshot of webpage. It should be Users can drag blocks together to build programs or something similar and relative.

Making a block undeletable seems to be broken in the latest code(906b62f). I'm working under the premise that one should not have to make a block immovable to make it not deletable.

If you create a block that has an output type, then select the link button in the upper left corner of the page, the URL in the address bar will be updated. Opening this link in a new tab will result in a broken view of the block if the block contains an output type. Removing the output type results in a link that works, though there will be no connector present for the output type.

For example: https://blockly-demo.appspot.com/static/demos/blockfactory/index.html#qzkeor

This link shows a corrupted block view in both Chrome and IE 11.

Code was moved from Google code to GitHub. As translatewiki.net wasn't informed, and doesn't have commit access, it's no longer possible to push L10n updates.

Translation has been disabled for now at translatewiki.net. If you'd like it to be re-enabled, please give me push access on the repo.

Hi,

I've just noticed that the latest commit above has broken something in the toolbox. You can see this in the toolbox demo - clicking on either Loops or Functions and the associated blocks all seem to be bunched up at the top of the toolbox. I've bisected and confirmed that the above commit is responsible.

Cheers,

David.