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

"Unknown" Exception When Viewing AccessibilityExample RNTester Page #5604

Closed
NickGerleman opened this issue Jul 28, 2020 · 7 comments · Fixed by #5849
Closed

"Unknown" Exception When Viewing AccessibilityExample RNTester Page #5604

NickGerleman opened this issue Jul 28, 2020 · 7 comments · Fixed by #5849

Comments

@NickGerleman
Copy link
Collaborator

image

Seems potentially new.

@ghost ghost added the Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) label Jul 28, 2020
@NickGerleman NickGerleman added this to the 0.63 milestone Jul 28, 2020
@chrisglein chrisglein added Area: Accessibility Area: Tests Recent Regression and removed Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) labels Jul 30, 2020
@NickGerleman
Copy link
Collaborator Author

NickGerleman commented Aug 1, 2020

Hmm, in our 0.63-stable branch this is even worse, just crashing immediately (seems to sometimes not crash though?). There's an exception due to Folly TypeError trying to deserialize a double as an int64.

I think it may be instant crash when not-web debugging, redbox if web debugging.

@NickGerleman
Copy link
Collaborator Author

The crash was outside of web debugging and due to an issue with our impl of accessibilityValue. That was fixed and backported but we still see this issue. Clicking on the LogBox after we see the issue leads to a crash internal to the compositor? Something funky is going on.

@asklar
Copy link
Member

asklar commented Aug 12, 2020

Filed a new issue for the actual app crash (5700), keeping this bug for the JS crash. That seems to be coming from JSTimers.callTimers ending up timing out but I'm not sure what that means or how to debug it on the JS side

@acoates-ms
Copy link
Contributor

This is due to us not having an implementation of the AccessibilityInfo native module.

An error is thrown when calling AccessiblityInfo.fetch. While that API is deprecated, there is another API isScreenReaderEnabled which it calls, which is not deprecated, and it also throws.

This should only affect people using the AccessiblityInfo APIs.

@NickGerleman
Copy link
Collaborator Author

Thanks for looking at that. Feels like this would be annoying for xplat apps, so we should maybe add a stub, but this doesn't feel super serious since it was never implemented before. IIRC AccessibilityInfo JS used to guard against a lack of module, but that seems to be happening less.

@acoates-ms
Copy link
Contributor

They are guarding against a lack of the module. But their guard is to have the promise immediately reject, not to return false.

@NickGerleman
Copy link
Collaborator Author

NickGerleman commented Aug 26, 2020

Oh... I think that's what our old stub did as well (we had a TS one some time ago). Seems like the AccessibilityInfo issue isn't new then?

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants