Bugzilla

In that case I think the logic in GeckoScreenOrientation needs changing so that the call to (un)lock doesn't update the screen orientation itself, otherwise you could run into the same problem, like
1. lock() call succeeds, updates the screen orientation in Gecko, which fires the orientationchange event and unblocks Marionette.
2. Marionette proceeds and calls lock() again.
3. Eventually we receive Android's configuration change message for the lock() call at 1.) and we're back at comment #13.

I.e. in that case I think we should only ever update the screen orientation in response to Android telling us about it, although that introduces a different problem: AFAIK onConfigurationChange isn't fired for 180°-rotations, so we never learn about those. The current logic means that if a lock call results in a 180° flip, at least the lock call itself updates the screen orientation to the correct new value.

In that case I think the logic in GeckoScreenOrientation needs changing so that the call to (un)lock doesn't update the screen orientation itself, otherwise you could run into the same problem, like
1. lock() call succeeds, updates itself the screen orientation in Gecko, which fires the orientationchange event and unblocks Marionette.
2. Marionette proceeds and calls lock() again with the next orientation.
3. Eventually we receive Android's configuration change message for the lock() call at 1.) and we're back at comment #13.

I.e. in that case I think we should only ever update the screen orientation in response to Android telling us about it, although that introduces a different problem: AFAIK onConfigurationChange isn't fired for 180°-rotations, so we never learn about those. The current logic means that if a lock call results in a 180° flip, at least the lock call itself updates the screen orientation to the correct new value.