Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProgressBarAndroid Component does not announce "disabled" #3

Closed
fabOnReact opened this issue Feb 1, 2022 · 4 comments
Closed

ProgressBarAndroid Component does not announce "disabled" #3

fabOnReact opened this issue Feb 1, 2022 · 4 comments

Comments

@fabOnReact
Copy link
Owner

fabOnReact commented Feb 1, 2022

facebook/react-native#30941 and react-native-progress-view/progress-bar-android#62

Description

When using a screen reader the ProgressBarAndroid component does not announce that it is disabled.
This issue is covered in-depth by parent issue facebook/react-native#30840

@fabOnReact fabOnReact changed the title Progress Bar values not announced on Screen Reader ProgressBarAndroid Component does not announce "disabled" Feb 1, 2022
@fabOnReact

This comment has been minimized.

@fabOnReact
Copy link
Owner Author

fabOnReact commented Feb 1, 2022

fabOnReact pushed a commit that referenced this issue Feb 4, 2022
Summary:
This diff adds `overflowInset` values in RN Android. These values are used to give  an enlarged boundary of a view group that also contains all its children layout. Here is [the post](https://fb.workplace.com/groups/yogalayout/permalink/2264980363573947/) that discuss more on why this is useful. I steal the pic in that post here as TLDR:

{F687030994}

In the above case, we will get overflowInset for ViewGroup A as something like `top: 0, right: -20, bottom: -20, left: 0`.

This has been added in the [Fabric core](https://fburl.com/code/f8c5tg7b) and [in IOS](https://fburl.com/code/vkh0hpt6). In Android, since we used to ignore all event coordinates outside of a ViewGroup boundary, this is not an issue. However, that caused unregistered touch area problem and got fixed in D30104853 (facebook/react-native@e35a963), which dropped the boundary check and made the hit test algorithm in [TouchTargetHelper.java](https://fburl.com/code/dj8jiz22) worse as we now need to explore all the child node under ReactRootNode.

This perf issue is getting obvious when a view loads too many items, which matches our experience with "Hover getting slow after scrolling", "Hover getting slow after going back from PDP view", and "The saved list view (in Explore) is very fast (because it has very few components)"

To fix this issue, I added the support to `overflowInset` to RN Android by
1. Sending the `overflowInset` values from Binding.cpp in RN Android as a separate mount instruction
2. Update `IntBufferBatchMountItem.java` to read the int buffer sent over JNI, and pass the `overflowInset` values to `SurfaceMountingManager.java`
3. Creating new interface `ReactOverflowViewWithInset.java` and extending the existing `ReactOverflowView.java` usages
4. Adding implementation of getter and setter for `overflowInset` in various views
5. Update `TouchTargetHelper.java` to read the values and check boundaries before exploring ViewGroup's children

Note that in #3 I didn't change `ReactOverflowView.java` interface directly. I am concerned about backward compatibility issues in case this interface is being used in OSS. I suggest we deprecate it as we are not using it anymore in our code.

Changelog:
[Internal][Android]

Reviewed By: JoshuaGross

Differential Revision: D33133977

fbshipit-source-id: 64e3e837fe7ca6e6dbdbc836ab0615182e10f28c
@fabOnReact fabOnReact pinned this issue Feb 6, 2022
@fabOnReact

This comment was marked as off-topic.

@fabOnReact fabOnReact unpinned this issue Feb 7, 2022
@fabOnReact fabOnReact pinned this issue Feb 8, 2022
@fabOnReact
Copy link
Owner Author

  • Check for other PRs fixing similar issue

@fabOnReact fabOnReact unpinned this issue Feb 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant