[0.63.1][Android] Dimensions API stops working randomly after a while

[cristianoccazinsp]

Please provide all the information requested. Issues that do not follow this format are likely to stall.

Description

Using Dimensions.get('window') and Dimensions.addEventListener(...) stops working/firing events randomly after a while.

I can't figure out exactly what triggers the issue, but after the event listener stops firing, calling get will also return incorrect values (e.g., portrait values even if in landscape). Note that the actual UI still works as expected (rotates/adjusts), but the Dimensions API just completely breaks.

After testing for a couple of hours, the bug seems to happen after a WebView is loaded (with https://github.com/react-native-community/react-native-webview). I can't tell yet whether this was caused by an upgrade in the WebView library or react native itself. I will be linking this issue there as well.

React Native version:

Run react-native info in your terminal and copy the results here.

info Fetching system and libraries information...
System:
    OS: macOS 10.15.4
    CPU: (4) x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
    Memory: 108.54 MB / 8.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.16.3 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.5, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      API Levels: 23, 26, 28, 29
      Build Tools: 28.0.3, 29.0.2
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.0 AI-193.6911.18.40.6626763
    Xcode: 11.5/11E608c - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_121 - /usr/bin/javac
    Python: 2.7.15 - /Library/Frameworks/Python.framework/Versions/2.7/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1 
    react-native: 0.63.1 => 0.63.1 
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

Provide a detailed list of steps that reproduce the issue.

1. Build a simple Android app with unlocked orientation (that is, allow all orientations)
2. Use Dimensions API: Dimensions.get('window') and Dimensions.addEventListener(...). For example, registering these on the root's component mount.
3. Rotate the device a few times and confirm Dimensions is firing the event
4. Mount a <WebView /> component and rotate a few times
5. Unmount the <WebView /> component
6. Rotate the device again. Observe how Dimensions events no longer fire, and Dimensions.get(...) always return the same values (i.e., they do not update when the UI rotates).

Some logcat warnings when the issue triggers:

2020-07-21 11:35:44.549 30678-31115/com.zinspector3.dev W/cr_media: Requires BLUETOOTH permission
2020-07-21 11:35:44.728 30678-31121/com.zinspector3.dev W/VideoCapabilities: Unrecognized profile 2130706433 for video/avc
2020-07-21 11:35:44.728 30678-31121/com.zinspector3.dev W/VideoCapabilities: Unrecognized profile 2130706434 for video/avc
2020-07-21 11:35:44.738 30678-31121/com.zinspector3.dev W/VideoCapabilities: Unrecognized profile 2130706433 for video/avc
2020-07-21 11:35:44.738 30678-31121/com.zinspector3.dev W/VideoCapabilities: Unrecognized profile 2130706434 for video/avc
2020-07-21 11:35:44.829 30678-31121/com.zinspector3.dev W/VideoCapabilities: Unrecognized profile 2130706433 for video/avc
2020-07-21 11:35:44.829 30678-31121/com.zinspector3.dev W/VideoCapabilities: Unrecognized profile 2130706434 for video/avc
2020-07-21 11:35:44.858 30678-31121/com.zinspector3.dev I/VideoCapabilities: Unsupported profile 4 for video/mp4v-es

-- close webview --

2020-07-21 11:41:34.078 31308-31308/com.zinspector3.dev E/chromium: [ERROR:aw_browser_terminator.cc(125)] Renderer process (32010) crash detected (code -1).

Note: react-navigation is also being used.

Expected Results

Dimensions API should not stop updating just because a possibly buggy component (WebView) is messing with the app.

Snack, code example, screenshot, or link to a repository:

Please provide a Snack (https://snack.expo.io/), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
You may provide a screenshot of the application if you think it is relevant to your bug report.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve

[cristianoccazinsp]

Update: Tried downgrading and this is definitely a 0.63.1 issue... I still don't know why would WebViews trigger it though.

[oliverdolgener]

Can confirm! The issue appears very ranromly but frequently. On native screens the orientation changes are detected correctly. But after switching to a webview screen and rotating the device it stops working and the dimensions either stay in portrait or landscape mode. After that no orientation changes are detected anymore. On iOS we haven't had any problems.

[chrisglein]

Seeing lots of recent issues on this: #29323 #29290 #29105
Let's try to get all the info into one issue. Do you think there's overlap there in any of those issues?

[cristianoccazinsp]

Those issues really seem related, although they seem to be getting the issue right away. From my testing, it only happens after opening a webview (or perhaps the webview uses something else that triggers it, such as a Modal/Dialog or screen navigation).

This issue seems quite critical, any work-arounds at least?

[tianjyan]

I have the same issue on my Application. Anyone has any workaround here ?

[mvrdrew]

There may definitely be some overlap with the issue we're having. Our app includes a module that uses UIWebView in its operation. I've not checked other screens, but the incorrect dimensions are definitely occurring on the screen that uses this library. We can't update the module to WKWebView so can't check if that also causes the issue, but there could be a connection.

[cristianoccazinsp]

For me, this is happening on Android only, so I wouldn't know about UIWebView.

I'm guessing most people implemented their app without rotation support, so they are not aware of this issue at all. For me, this is quite critical and needs urgent attention.

[mvrdrew]

Oh yes, you're right! We're having this issue on Android only, so it obviously has nothing to do with the iOS stuff. I'm definitely having one of those days... :)

It's a complete blocker for us upgrading as well, unfortunately.

[cristianoccazinsp]

@fabriziobertoglio1987 I know you have been getting your hands dirty by debugging some very deep react native bugs. Sorry about tagging you here, but do you have any ideas what could be this bug? Seems like extremely serious since it cripples Android apps.

[fabOnReact]

Thanks a lot @cristianoccazinsp currently I only have weeekends to do opensource, unluckily I never worked with the ReactNative Dimensions SourceCode

My todos for next weeks are finishing #29117 and #29070

Then I can take a look at this.
The first step in solving all bugs is creating a Minimum Reproducible Example and start understanding all not related APIs.

Does it really need Webview and react-navigation to reproduce?
What is really causing this issue?
Is this issue caused from the JavaScript of Java ReactNative API?

Mount a component and rotate a few times

What does Mounting, Unmounting, Rotating actually do to stop the event to fire? Can we get insight on the source-code and how does WebView, ReactNavigation affect the rotation/event firing?

But N.1, reproducing the bug without React-Navigation and Webview, because this exclude a large amount of sourcecode from investigation

It is much easier to remove a prop style and notice that the issue still reproduce, rather then investigate all the JavaScript and Java API behind style prop, debug it and understand that the prop is not relevant for this issue

So the easiest way to solve the bug is by testing the RN API and see the difference in the reproduction.

I bookmarked and follow this issue, I'll try to solve it once finishing #29117 and #29070 are completed. Thanks. I wish you a good day

[cristianoccazinsp]

I will try to test a fresh project to discard webviews and navigation causing issues. But it really seems like something internal from RN is breaking in a very bad way and I don't really see how other libraries could affect it.

[cristianoccazinsp]

Repro here: https://github.com/cristianoccazinsp/react-native-dims-bug

Although the webview seems needed to trigger the bug, I believe it is something related to either surface handling or event emitters (that the webview use), but technically any component could trigger the bug.

Running the above example: just run it on android and rotate the device a few times, dimensions will stop updating right away.

[TGibsonn]

I also encountered this issue while handling rotation detection with a web view - it happens immediately on the first render. In my case, a call to Orientation.lockToLandscape() or Orientation.lockToPortrait() would be invoked before retrieving the window dimensions via Dimensions.get("window"). The dimension values, however, would not update after the orientation change.

The packages used:

react-native@0.63.2
react-native-webview@10.4.1
react-native-orientation-locker@1.2.0

A strange behavior worth noting: When changing to a separate tab in my app (using react-navigation-tabs), locking the orientation portrait->landscape->portrait, then returning to the web view tab, the Dimension API suddenly begins working flawlessly. I would speculate that the issue only occurs after some sort of "initialization" state.

Also, referencing this issue from react-native-orientation-locker regarding this. There are a few potentially helpful workarounds available.

[cristianoccazinsp]

Thanks for the insight @TGibsonn . For now, we have decided to roll back to RN 0.62.2 until this and other major bugs are resolved.

[GKotsovos]

Is there anything new regarding this issue? Anything we can do in order to help? This seems to block teams wanting to update to latest RN version right now :/

[cristianoccazinsp]

As far as I know, we can only wait and stay with 0.61.x . This hasn't brought a lot of attention because most apps use locked rotation and I guess rarely use webviews.

[cam-shaw]

@fabriziobertoglio1987 Can't provide too much information at the moment, but I can confirm we're also getting this issue for Android only on 0.63.2. We'll be having to rollback the RN update 😞 . Happy to provide info where I can.

We do use react-native-webview, but it's not loaded on screen before we get this issue. I wonder if pointing out this library though is just a red herring.

[cristianoccazinsp]

Still an issue, and RN 0.64 is just around the corner. This issue could really use some attention since migration is impossible until this is resolved and apps will already lag behind with RN updates.

[meshaabi]

possibly related - the 'change' listener doesn't fire at all 0.63.3 iOS Simulator, traced it from onLayout not firing on orientation change.

[nickfujita]

@luisnaranjo733 Thanks for letting us know that the fix has been added to 0.63.4. Would you possibly know who I can get in contact with to get WalmartLabs hosted Android Maven repo updated?
https://mvnrepository.com/artifact/com.walmartlabs.ern/react-native

[cristianoccazinsp]

There's yet another issue when combined with react-native-webview on iOS.

When rendering a webview that has a video player, if the user enters fullscreen and then rotates the device, Dimensions.get('window') return switched values (width -> height, height ->width). For some reason, Dimensions.get('screen') work just fine.

[haorh]

There's yet another issue when combined with react-native-webview on iOS.

When rendering a webview that has a video player, if the user enters fullscreen and then rotates the device, Dimensions.get('window') return switched values (width -> height, height ->width). For some reason, Dimensions.get('screen') work just fine.

I actually face this issue at RN 0.59.9. Dimension 'screen' works while 'window' doesnt when rotating the screne in video player webview (react-native-youtube-iframe 1.4.1).

[cristianoccazinsp]

Does anyone know if this has been resolved with 0.64.0?

[luisnaranjo733]

@nickfujita - apologies, I don't actually know how to go about doing that. What I do know is that this fix is available in 0.63.4 as well as 0.64.0

@cristianoccazinsp - this fix is definitely deployed in 0.64.0, assuming we are talking about the same one. You mentioned something about iOS, if that's the case, that sounds like a totally unrelated thing because the fix I pushed for was very Android specific.

react-native-community/releases#212 (comment)

[zeevl]

Unfortunately I'm still seeing this issue with 0.64.0.

It's android only, and happens pretty consistently, but only after a WebView has been loaded.

Oddly enough, it doesn't happen in 0.63.4, so this may be a new bug not addressed by the aforementioned PRs.

[jmsbrett]

Still seeing this in 64.1 too.

[luisnaranjo733]

@jmsbrett this is fixed in 64.2. I didn't realize how RN branching worked when I pushed for this to get cherry-picked into 63. I thought that landing it in the master branch was enough for it to naturally flow back into the 64 release, but I was wrong. This is why the first few 64 releases didn't include the fix.

https://github.com/facebook/react-native/releases/tag/v0.64.2

Dimension update events are now properly sent following orientation change (a6a4d33 by @ajpaulingalls)

[kelset]

Since commit landed in 64 I guess we can close this off?

[RemyMachado]

I'm having this issue in RN 65.1.
As soon as I'm loading this library component: https://github.com/RepairShopr/react-native-signature-capture.
It seems closely related.

[jmsbrett]

@RemyMachado I was having an issue with the Dimensions API and ended up using react-native-orientation-locker. Maybe test your component and supplement the Dimensions API with react-native-orientation-locker to get a baseline? I am not a maintainer so I really do not know the underlying work of the Dimensions API but from my research RN orientation-locker actually works by listening to the device directly and does not abstract it to an API.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.