fix: Ephemeral focus being taken twice in field-slider and field-angle
#2521
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 task
|
Confirming that with the latest google/blockly#9051, fixes to We'll need #2509 working and merged with another beta release of v12 in order for CI to pass here. |
BenHenning
added a commit
to google/blockly
that referenced
this pull request
May 14, 2025
## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Needed for fixing google/blockly-samples#2514 and google/blockly-samples#2515. ### Proposed Changes Update `FieldInput` along with drop-down and widget divs to support disabling the automatic ephemeral focus functionality. ### Reason for Changes As mentioned in google/blockly-samples#2514 (comment) both google/blockly-samples#2514 and google/blockly-samples#2515 were caused by the custom fields leading to both drop-down and widget divs simultaneously taking ephemeral focus (and that's not currently allowed by `FocusManager`). This change updates both widget and drop-down divs with _optional_ parameters to conditionally disable automatic ephemeral focus so that `FieldInput` can, in turn, be customized with disabling automatic ephemeral focus for its inline editor. Being able to disable ephemeral focus for `FieldInput` allows the custom fields' own drop-down divs to take and manage ephemeral focus, instead, avoiding the duplicate scenario that led to the runtime failure. Note that the drop-down div change in this PR is completely optional, but it's added for consistency and to avoid future scenarios of breakage when trying to use both divs together (as a fix is required in Core without monkeypatching). It's worth noting that there could be a possibility for a more 'proper' fix in `FocusManager` by allowing multiple calls to `takeEphemeralFocus`, but it's unclear exactly how to solve this consistently (which is why it results in a hard failure today). The main issue is that the current focused node can change from underneath the manager (due to DOM focus changes), and the current focused element may also change. It's not clear if the first, last, or some other call to `takeEphemeralFocus` should take precedent or which node to return focus once ephemeral focus ends (in cases with multiple subsequent calls). ### Test Coverage No new tests were added, though common field cases were tested manually in core's simple playground and in the plugin-specific playgrounds (per the original regressions). The keyboard navigation plugin test environment was also verified to ensure that this didn't alter any existing behavior (it should be a no-op except for the two custom field plugins). Automated tests would be nice to add for all three classes, perhaps as part of #8915. ### Documentation The code documentation changes here should be sufficient. ### Additional Information These changes are being done directly to ease solving the above samples issues. See google/blockly-samples#2521 for the follow-up fixes to samples.
|
I think if rebased now, this should be good to go, right? |
Yup, just getting it ready. |
1 task
|
Verified this still works locally in both plugins' test environments, so this should be ready for review now. |
rachel-fenichel
approved these changes
May 15, 2025
This was referenced May 15, 2025
1 task
BenHenning
added a commit
to google/blockly
that referenced
this pull request
May 22, 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 #9078 Fixes part of #8915 (new tests) ### Proposed Changes Exposes the ability to disable ephemeral focus management for drop-down divs that are shown using `showPositionedByBlock` or `showPositionedByField`. Previously, this was only supported via `show`, but the former methods are also used externally. This allows the underlying issue reported by #9078 to be fixed downstream for cases when both the widget and drop-down divs are opened simultaneously. This PR also introduces tab indexes for both widget and drop-down divs (which were noticed missing when adding tests). This is because, currently, taking ephemeral focus on for a node that doesn't have a tab index will do nothing. This fix is useful for future screen reader work, and doesn't have obvious impacts on existing core or keyboard navigation behaviors (per testing and reasoning). ### Reason for Changes Exposing the ability to disable ephemeral focus management for all public API entrypoints for showing the divs is crucial for providing the maximum flexibility when downstream apps use both the widget and drop-down divs together. This should ensure that all of these cases can be correctly managed in the same way as google/blockly-samples#2521. ### Test Coverage This introduces a bunch of new tests that were missing originally for both widget and drop-down div (including specifically verifying ephemeral focus). As part of the drop-down div tests, it also introduces actual positioning logic. This isn't great, but it's somewhat reasonable and robust against page changes (since the actual mocha results can move where the elements will end up on the page). These changes have also been manually tested with both the core simple playground and the keyboard experiment plugin's test environment with no noticed regressions in either. The plugin's tests have also been run against these changes to ensure no new breakages have been introduced. ### Documentation No documentation changes beyond the code ones introduced in this PR should be needed. ### Additional Information The new tests may actually act as a basis for avoiding the test backdoor that's used today for the positioning tests for drop-down div tests. This doesn't replace those existing tests nor does it cover other behaviors and entrypoints that would be worth testing, but testing ephemeral focus is a nice improvement (especially in the context of what this PR is fixing).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The basics
The details
Resolves
Fixes #2514
Fixes #2515
Proposed Changes
This updates the custom field implementations for
field-sldierandfield-angleto use new functionality introduced in google/blockly#9051.Reason for Changes
The regressions reported in #2514 and #2515 were introduced due to the custom fields introducing a scenario where both widget and drop-down divs attempted to take ephemeral focus. This isn't allowed currently as core's
FocusManagerhas no tie breaking functionality for ephemeral focus, so the second attempt to request it throws a runtime failure.The functionality introduced in google/blockly#9051 allows the custom fields to, through
FieldInput, disable the automatic ephemeral focus management forFieldInput's inline editor (which uses widget div) so that the custom fields' drop-down div editors can properly take focus, instead.Test Coverage
This has been manually tested locally.
Automated tests are, unfortunately, non-trivial here since verifying focus-related behavior (at least through user interactions) requires a working DOM and is very tricky to make work with Node.js. These are tests that would likely be better suited via webdriver, instead. #2527 has been filed to track this work.
Documentation
No additional documentation is needed here.
Additional Information
This requires google/blockly#9051 in order to work.