Fix: pointercancel event is not handled

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!

[nianxy]

The basics

• I validated my changes

The details

Resolves

Fixes
#9249

Proposed Changes

Listen to the 'pointercancel' event

Reason for Changes

The 'pointercancel' event is not handled, which leads to the abnormal

Test Coverage

Manually tested.

Documentation

None

Additional Information

None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:

• You can find tips about contributing to Blockly and how to validate your changes on our developer site.
• All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
• We use conventional commits to make versioning the package easier. Make sure your commit message is in the proper format or learn how to fix it.
• If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the style guide.
  Thank you for opening this PR! A member of the Blockly team will review it soon.

[maribethb]

Thank you for filing this PR and reporting the issue it goes with!

This is a creative approach that will essentially bind any registered pointerup events to also fire when a pointercancel event is received as well. But I think if a pointercancel event is received, we don't necessarily want to fire all the same events that would fire on a true pointerup. We should definitely cancel the in-progress gesture, but since this affects any event that is registered through conditionalBind we should be cautious as it could have unintended effects. The pointercancel event may be triggered when "The browser decides that the user started pointer input accidentally. This can happen if, for example, the hardware supports palm rejection to prevent a hand resting on the display while using a stylus from accidentally triggering events." (mdn) and if that were to happen it's possible we'd want to abort a move rather than finish it, for example.

cc @rachel-fenichel for more input on this because you have more experience with touch handling.

[nianxy]

Yes, my changes are risky.

My App users are children, and they often use their fingers to control the blocks on the pad. I have received many feedback saying that the blocks sometimes move unexpectedly. I watched their screen records attached, and I'm sure the problem is caused by the unhandled pointercancel event.

In order to quickly fix this problem, I temporarily patched my code in my App. I listen to the pointercancel event and emit a pointerup event to the workspace when I receive a pointercancel event. After doing this about a week ago, I haven't received any report on this problem till now.

Since I haven't fully read the code of Blockly, I think my PR may be inconsiderate. If so, I'm looking forward to your advice on how to fix the problem more sensibly.

[maribethb]

Thank you so much for your patience. After discussing this internally with the team, we think this is ok to try given that this is how things work for mouse users already, and we don't have an established way to abort an in-progress gesture other than completing it. Thank you for contributing and testing the fix!