This repository was archived by the owner on Feb 25, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6k
makes android semanticsnode to ignore hittest if it is not focusable #22205
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -204,6 +204,70 @@ public void itAnnouncesRouteNameWhenAddingNewRoute() { | |
assertEquals(sentences.get(0).toString(), "new_node2"); | ||
} | ||
|
||
@Test | ||
public void itIgnoresUnfocusableNodeDuringHitTest() { | ||
AccessibilityViewEmbedder mockViewEmbedder = mock(AccessibilityViewEmbedder.class); | ||
AccessibilityManager mockManager = mock(AccessibilityManager.class); | ||
View mockRootView = mock(View.class); | ||
Context context = mock(Context.class); | ||
when(mockRootView.getContext()).thenReturn(context); | ||
when(context.getPackageName()).thenReturn("test"); | ||
AccessibilityBridge accessibilityBridge = | ||
setUpBridge(mockRootView, mockManager, mockViewEmbedder); | ||
ViewParent mockParent = mock(ViewParent.class); | ||
when(mockRootView.getParent()).thenReturn(mockParent); | ||
when(mockManager.isEnabled()).thenReturn(true); | ||
when(mockManager.isTouchExplorationEnabled()).thenReturn(true); | ||
|
||
TestSemanticsNode root = new TestSemanticsNode(); | ||
root.id = 0; | ||
root.left = 0; | ||
root.top = 0; | ||
root.bottom = 20; | ||
root.right = 20; | ||
TestSemanticsNode ignored = new TestSemanticsNode(); | ||
ignored.id = 1; | ||
ignored.addFlag(AccessibilityBridge.Flag.SCOPES_ROUTE); | ||
ignored.left = 0; | ||
ignored.top = 0; | ||
ignored.bottom = 20; | ||
ignored.right = 20; | ||
root.children.add(ignored); | ||
TestSemanticsNode child = new TestSemanticsNode(); | ||
child.id = 2; | ||
child.label = "label"; | ||
child.left = 0; | ||
child.top = 0; | ||
child.bottom = 20; | ||
child.right = 20; | ||
root.children.add(child); | ||
TestSemanticsUpdate testSemanticsUpdate = root.toUpdate(); | ||
accessibilityBridge.updateSemantics(testSemanticsUpdate.buffer, testSemanticsUpdate.strings); | ||
|
||
ArgumentCaptor<AccessibilityEvent> eventCaptor = | ||
ArgumentCaptor.forClass(AccessibilityEvent.class); | ||
verify(mockParent, times(2)) | ||
.requestSendAccessibilityEvent(eq(mockRootView), eventCaptor.capture()); | ||
AccessibilityEvent event = eventCaptor.getAllValues().get(0); | ||
assertEquals(event.getEventType(), AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED); | ||
|
||
// Synthesize an accessibility hit test event. | ||
MotionEvent mockEvent = mock(MotionEvent.class); | ||
when(mockEvent.getX()).thenReturn(10.0f); | ||
when(mockEvent.getY()).thenReturn(10.0f); | ||
when(mockEvent.getAction()).thenReturn(MotionEvent.ACTION_HOVER_ENTER); | ||
boolean hit = accessibilityBridge.onAccessibilityHoverEvent(mockEvent); | ||
|
||
assertEquals(hit, true); | ||
|
||
eventCaptor = ArgumentCaptor.forClass(AccessibilityEvent.class); | ||
verify(mockParent, times(3)) | ||
.requestSendAccessibilityEvent(eq(mockRootView), eventCaptor.capture()); | ||
event = eventCaptor.getAllValues().get(2); | ||
assertEquals(event.getEventType(), AccessibilityEvent.TYPE_VIEW_HOVER_ENTER); | ||
assertEquals(accessibilityBridge.getHoveredObjectId(), 2); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems to be the only way to get the event target. The event.getSource returns null even after we call setSource. |
||
} | ||
|
||
@Test | ||
public void itAnnouncesRouteNameWhenRemoveARoute() { | ||
AccessibilityViewEmbedder mockViewEmbedder = mock(AccessibilityViewEmbedder.class); | ||
|
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In iOS, we ask a11y service to ignore the node entirely by setting isAccessibilityElement = NO when the condition is met.
So I "think" this is ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do you see this in the iOS bridge? I'm looking at https://github.com/flutter/engine/blob/master/shell/platform/darwin/ios/framework/Source/SemanticsObject.mm#L233 and don't see focusability there. We use a few other things theree that we're not using here though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, we do use most of the other logic from isFocusable in the iOS version
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I mean iOS uses most of other logic from isFocusable except the addtional IS_FOCUSABLE flag. but i think we are trying to achieve the same thing in iOS. The isAccessibilityElement =NO is more strict than AccessibilityNodeInfo.setFocusable(false) that the former will not absorb hit test, and i think we want to same behavior here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If not, we can go with implementing changes in framework as I mentioned in the PR description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is probably fine. Let's just add a test to cover it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok :) will do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if we have any cases where we use a non-focusable semantics node to hide a node behind it from hit testing. Do we need that use case for anything?
Do we, for example rely on the app bar to block focusing elements that are scrolled behind it in the scrollable list? I think we don't, but we should check.
If we cannot come up with a case where we need this particular behavior, this change seems fine. We should add a test, though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the sliver app bar does not overlay with the sliverlist, so nothing should be behind the appbar. I can't think of a use case where user might want to block something using non-focusable semantics node. It is already weird that if you have overlapping UI components.