Fixing block deletions problems with some sticky comments

[jguille2]

Reported at forum bug reports.

Fixing this issue I saw that there were three related problems:

• Deleting the first (only the first) block of a C input when there are other blocks in that C-input with comments.
• Deleting the whole script (C-block) with comments inside
• Similar actions done by keyboard edition.

At code:

• There were three prepareToBeGrabbed calls without params, and this (the missing hand param) causes the problem (it is needed when threre are comments, to trigger starFollowing function).
• Fixing this, appears another problem, because this triggering action starts comments startFollowing. But this action (shadows and more) are stopped by the drop event... and here we have no drop event. So, I've changed these functions adding an allAtOnce param to control this behavior.

That's all!
Joan

[jmoenig]

Thanks, Joan! This is a somewhat hairy issue, let me think about this some more. I'll most likely pull this along with the others for the next release.

[jmoenig]

Hi @jguille2, I just came across this issue (or is it just a similar / related one?) as I was going through the blocks.js code to refactor it. So I thought about the quickest way to fix it and came up with this: e74c95a
This seems to fix it for me. What do you think?
Thanks!

[jguille2]

Hi @jmoenig ,

The problem of this solution is the second point I detected:

• There were three prepareToBeGrabbed calls without params, and this (the missing hand param) causes the problem (it is needed when threre are comments, to trigger starFollowing function).

• Fixing this, appears another problem, because this triggering action starts comments startFollowing. But this action (shadows and more) are stopped by the drop event... and here we have no drop event. So, I've changed these functions adding an allAtOnce param to control this behavior.

You can see the the "attaching line" of the comment turns to grey (behavior of a drag and drop action) and that state (that "startFollowing" state without stopping) causes other IDE crashes.

This is the reason I had to add this "allAtOnce" param, because I see the missing "hand", but the real problem is that we don't want to "startFollowing" because we can't stop it (he have no "drop" event).

Joan

[jmoenig]

Ah, okay, so there's more to the issue than I suspected, thanks for the explanation, @jguille2 !
I'll keep this PR open and integrate it along with the others then...