search

zulip / zulip-mobile

Zulip mobile apps for Android and iOS.
https://zulip.com/apps/
Apache License 2.0
1.28k stars 643 forks source link

No internet connection banner does not disappear on regaining connection. #3485

Open ishammahajan opened 5 years ago

ishammahajan commented 5 years ago

As discussed on chat, there have been multiple reports of the No Internet Connection banner not disappearing when it should, as the internet connection resets. To reproduce, login to the Zulip realm and turn off the internet connection. Wait for a few seconds and resume the connection. The banner should persist. (video)

As pointed out helpfully by @borisyankov in the chat, these are a few pointers:

For anyone investigating or curious to learn more:

ishammahajan commented 5 years ago

Solution possibly related to #3281.

ishammahajan commented 5 years ago

I won't be able to resolve this issue because of some issues with the iOS simulator. iOS simulators do not propagate offline --> online events as described in this issue and this one. This works well on an android device, and as such has been tested. Due to a lack of access to an iOS physical device it becomes impossible for me to debug this.

This comment is just as a PSA, ensure access to an iOS device before trying to solve this issue.

gnprice commented 5 years ago

Thanks @ishammahajan for filing this and digging into it!

Since you weren't able to reproduce on Android (and I don't think I've seen this in my own regular use on my Android phone), it sounds like this is probably iOS-specific. Adding our label for that.

chrisbobbe commented 4 years ago

It’s working correctly for me on iOS 13.3 with Zulip 26.20.143; the banner appears when I switch on airplane mode, and disappears when I switch it off. Has anyone noticed this still happening, and on which version?

chrisbobbe commented 4 years ago

https://github.com/zulip/zulip-mobile/commit/876f22d1aec9580ac053849b2c0ffaf1891b99fb for issue https://github.com/zulip/zulip-mobile/issues/3602, released with 26.13.136 in November, 2019, was a revert of some code that animated the entrance/exit of the banner, but with a bug where it would get stuck and show up when it shouldn't.

But symptoms were only reported on Android, and it seemed like it was possible to make the banner go away with further interactions. This may be no relation to the present issue — or, it was a bug whose root cause affected both platforms, and we didn't realize.

We may be able to rule out one reason the root cause would be platform-specific. The animation was on the 'height' attribute, so the device-specific native driver was not being used; the animation had to have been implemented entirely in JavaScript, which runs on both platforms. (It's one of the caveats described in the Animated library's doc here), and you can check that useNativeDriver was false in the revert commit linked above). It is, however, possible to conditionalize on the platform at runtime, in JavaScript; we could see if that's being done.

Possibly, its symptoms were observed to be platform-specific because there was an Android-particular pattern triggering entrances and exits of the banner very rapidly; note, in the commit message,

When disconnecting from a VPN on Android 9 and later, the connection state goes from 'vpn' to 'none' to 'wifi' very quickly.

I believe it was never concluded that https://github.com/zulip/zulip-mobile/issues/3602 had an Android-specific root cause. Could it be that some JavaScript run in that animation on both Android and iOS just can't handle very rapid state changes between "visible" and not?

@ray-kraesig, any thoughts?

rk-for-zulip commented 4 years ago

I believe it was never concluded that #3602 had an Android-specific root cause. Could it be that some JavaScript run in that animation on both Android and iOS just can't handle very rapid state changes between "visible" and not?

I have no evidence against it!

(As a hacky test, if we can manage to reproduce the bug on a physical Pie device, it might be possible to record the actual sequence of event times, and then issue mock disconnection events with similar timings in order to try to reconstruct the bug on an emulator, earlier-Android, or iOS device.)