Check for duplicates
Description
We have been catching up with the behaviour of Page Up / Down and Home / End as we didn't ship this in MakeCode. I think we have found a couple of bugs, but also have thoughts on the behaviour in some areas as well.
Bugs
When a container end statement position is focused, pressing End moves focus into the previous block's end statement position. In this case, I'd expect End to do nothing at all.
https://github.com/user-attachments/assets/55fc8e03-f118-4d11-9c5e-aa869caa5d04
When a container block is focused, pressing End moves focus to the container end statement position, but this position is in the wrong place. It focuses an impossible position between the top inside edge of the container and the top of the statement block inside. This is normally unreachable with Up / Down.
https://github.com/user-attachments/assets/cfdc57da-68ba-4311-a75d-0bc952140469
Thoughts on behaviour
Sometimes it feels logical, and sometimes it feels unpredictable. We think it would make more sense if it followed conventions used for keyboard controls in a grid, or put another way, would move focus to where the arrow keys normally would if they were held down while scoped to the current stack. Details below:
- Page Up - moves to the first block in the stack accessible by using the Up arrow. Effectively what pressing the Up arrow multiple times would do, except scoped to the currently focused stack. No behaviour change.
- Page Down - moves to the last block in the stack accessible by using the Down arrow. Effectively what pressing the Down arrow multiple times would do, except scoped to the currently focused stack. Behaviour change - Page Down no longer traverses / moves focus right into block inputs.
- Home - moves to the left-most focusable position in the block accessible by using the Left arrow which is (almost?) always the block itself.
- End - moves to the right-most focusable position in the block accessible by using the Right arrow. Lots of behaviour change. E.g., When focused on a statement & container block, End would no longer focus the end statement position.
- Ctrl/Cmd + Home - moves to the first focusable position on the workspace (excluding the workspace itself). No behaviour change.
- Ctrl/Cmd + End - moves to the last focusable position on the workspace. Behaviour change - this doesn't just move to the last block, but moves to the last input. In a non-looping world, this would mimic what holding the Down arrow would do until you hear the end of program beep, followed by holding the Right arrow until you hear the end of program beep.
If the above is applied, then Home / End always work, even if you are currently focused on any input or field in a block. Let's say the second input of 3. End moves to the third input, home moves to the parent block.
These shortcuts should respect ltr and rtl layouts.
Reproduction steps
N/A - see bug section of the above.
Use the Blockly live demo and paste Blockly.ShortcutItems.registerNavigationShortcuts() in the devtools console to turn on these shortcuts.
Priority
Work effort: likely significant, but depends on the changes ultimately made.
Impact: low in a way as this feature is opt-in, but potentially has lots of added value to applications that make use of it. We think that some changes are required before MakeCode can opt-in to these additional navigation shortcuts.
Stack trace
Screenshots
No response
Browsers
No response
Check for duplicates
Description
We have been catching up with the behaviour of Page Up / Down and Home / End as we didn't ship this in MakeCode. I think we have found a couple of bugs, but also have thoughts on the behaviour in some areas as well.
Bugs
When a container end statement position is focused, pressing End moves focus into the previous block's end statement position. In this case, I'd expect End to do nothing at all.
https://github.com/user-attachments/assets/55fc8e03-f118-4d11-9c5e-aa869caa5d04
When a container block is focused, pressing End moves focus to the container end statement position, but this position is in the wrong place. It focuses an impossible position between the top inside edge of the container and the top of the statement block inside. This is normally unreachable with Up / Down.
https://github.com/user-attachments/assets/cfdc57da-68ba-4311-a75d-0bc952140469
Thoughts on behaviour
Sometimes it feels logical, and sometimes it feels unpredictable. We think it would make more sense if it followed conventions used for keyboard controls in a grid, or put another way, would move focus to where the arrow keys normally would if they were held down while scoped to the current stack. Details below:
If the above is applied, then Home / End always work, even if you are currently focused on any input or field in a block. Let's say the second input of 3. End moves to the third input, home moves to the parent block.
These shortcuts should respect ltr and rtl layouts.
Reproduction steps
N/A - see bug section of the above.
Use the Blockly live demo and paste
Blockly.ShortcutItems.registerNavigationShortcuts()in the devtools console to turn on these shortcuts.Priority
Work effort: likely significant, but depends on the changes ultimately made.
Impact: low in a way as this feature is opt-in, but potentially has lots of added value to applications that make use of it. We think that some changes are required before MakeCode can opt-in to these additional navigation shortcuts.
Stack trace
Screenshots
No response
Browsers
No response