Skip to content

Conversation

@RoboErikG
Copy link
Contributor

The basics

The details

Resolves

Fixes

Proposed Changes

Reason for Changes

Add private keyword to variableChangeCallback. This was requested for #8980 but didn't make it in because auto-merge was enabled.

Test Coverage

Documentation

Additional Information

@RoboErikG RoboErikG requested a review from a team as a code owner May 6, 2025 18:10
@RoboErikG RoboErikG requested a review from maribethb May 6, 2025 18:10
@github-actions github-actions bot added the PR: fix Fixes a bug label May 6, 2025
@RoboErikG RoboErikG removed the request for review from maribethb May 6, 2025 18:12
@RoboErikG RoboErikG merged commit eb5181e into RaspberryPiFoundation:rc/v12.0.0 May 6, 2025
11 checks passed
@maribethb
Copy link
Contributor

It doesn't need to be @internal if it's private. But this is like P5 to fix.

BenHenning added a commit that referenced this pull request May 6, 2025
## The basics

- [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change)

## The details
### Resolves

Fixes #8994

### Proposed Changes

This removes an error that was previously thrown by `FocusManager` when attempting to focus an invalid node (such as one that's been removed from its parent).

### Reason for Changes

#8994 (comment) goes into more detail. While this error did cover legitimately wrong cases to try and focus things (and helped to catch some real problems), fixing this 'properly' may become a leaky boat problem where we have to track down every possible asynchronous scenario that could produce such a case. One class of this is ephemeral focus which had robustness improvements itself in #8981 that, by effect, caused this issue in the first place. Holistically fixing this with enforced API contracts alone isn't simple due to the nature of how these components interact.

This change ensures that there's a sane default to fall back on if an invalid node is passed in. Note that `FocusManager` was designed specifically to disallow defocusing a node (since fallbacks can get messy and introduce unpredictable user experiences), and this sort of allows that now. However, this seems like a reasonable approach as it defaults to the behavior when focusing a tree explicitly which allows the tree to fallback to a more suitable default (such as the first item to select in the toolbox for that particular tree). In many cases this will default back to the tree's root node (such as the workspace root group) since sometimes the removed node is still the "last focused node" of the tree (and is considered valid for the purpose of determining a fallback; tree implementations could further specialize by checking whether that node is still valid).

### Test Coverage

Some new tests were added to cover this case, but more may be useful to add as part of #8910.

### Documentation

No documentation needs to be added or updated as part of this (beyond code documentation changes).

### Additional Information

This original issue was found by @RoboErikG when testing #8995. I also verified this against the keyboard navigation plugin repository.
@RoboErikG RoboErikG deleted the add-private branch June 23, 2025 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR: fix Fixes a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants