"screen is blocked" doesn't disappear

[459below]

If one was to spam the proximity sensor with fast "near" and "far" events the fragment showing "SCREEN IS BLOCKED" stays on screen forever, effectively blocking the screen for the remainder of the call. Though the irony is funny if the screen is blocked by a rouge fragment saying "SCREEN IS BLOCKED", it actually gets pretty annoying. This occurs on a not so recent S3 running AOSP 4.4.

I suppose this bug may be found somewhere in org.jitsi.android.gui.call.ProximitySensorFragment.java. I will take a look into this class hopefully in the next couple of days.

[459below]

I did some testing and it seems that in the case of the eternally blocked screen the call
return (ScreenOffDialog) fm.findFragmentByTag("screen_off_dialog"); fails and returns a null pointer. And screenOn checks for that, but won't throw any kind of error.

[459below]

So if I understood everything correctly this should prevent it 459below@bb5973c I certainly couldn't produce this error yet using this fix.

If one was to spam the proximity sensor it seems return (ScreenOffDialog) fm.findFragmentByTag("screen_off_dialog"); sometimes fails to return the screen_off_dialog. Thus at this time screenOn cannot dismiss the dialog. The next time (and this is the part I'm not certain about) the proximity sensor triggers onSensorChanged it will lay another screen_off_dialog on top of the other one. So screenOn will remove the top one and the bottom one will stay there forever.

[459below]

So I tried to reproduce this issue on a S5 running Samsung's stock 5.0 ROM and I couldn't. I suppose it doesn't affect many devices or ROMs then.

[talkinggoat]

I have an Asus Z00AD and I can confirm this issue, as well.

[459below]

I have the mentioned patch implemented in this release https://github.com/459below/jitsi-android/releases/tag/0.0.3

If you would mind testing this I could mark it as fixed in my fork.