While I was diagnosing bug 1895742, I found a test case causing "MOZ_ASSERT_UNREACHABLE: nsEventStatus_eConsumeNoDefault should involve a valid APZHandledResult" (bug 1852854) reliably. Attaching file is the test case, STR is just trying to scroll down not quickly. What's going on there is that 1) there's an active touch-start event listener so that we wait for the result of the event listner 2) when the first touch-move event is received 2-1) the APZEventResult for the touch-move event is initialized with `mHandledResult = Nothing()` since [the target APZ is the root and the event needs to be dispatched to the content](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/gfx/layers/apz/src/APZInputBridge.cpp#37-51) 2-2) we fall into [this if (block->UpdateSlopState(aEvent, consumable) block](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/gfx/layers/apz/src/InputQueue.cpp#201-203), thus the event result becomes nsEventStatus_eConsumeNoDefault Thus the assertion happens. So now I am pretty sure the assertion is invalid, it is a possible scenario. A question here is that what the best way to handle the scenario is? An easy way I can think of is to send the INPUT_RESULT_IGNORED state as it is (this is what we are currently doing) then ignore it in the android-component. An alternative way is to let APZ not send the INPUT_RESULT_IGNORED state wait for more touch-move events until APZ escapes from in slop state, and once after APZ escaped from the state, send a proper InputResultDetail to the android-component. I've confirmed locally the former way fixes bug 1852854, but bug 1852854 case is slightly different from the attached test case, in that bug case there's `touch-action: none` style so that INPUT_RESULT_IGNORED should not happen.
Bug 1897345 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
While I was diagnosing bug 1895742, I found a test case causing "MOZ_ASSERT_UNREACHABLE: nsEventStatus_eConsumeNoDefault should involve a valid APZHandledResult" (bug 1852854) reliably. Attaching file is the test case, STR is just trying to scroll down not quickly. What's going on there is that 1) there's an active touch-start event listener so that we wait for the result of the event listner 2) when the first touch-move event is received 2-1) the APZEventResult for the touch-move event is initialized with `mHandledResult = Nothing()` since [the target APZ is the root and the event needs to be dispatched to the content](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/gfx/layers/apz/src/APZInputBridge.cpp#37-51) 2-2) we fall into [this if (block->UpdateSlopState(aEvent, consumable) block](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/gfx/layers/apz/src/InputQueue.cpp#201-203), thus the event result becomes nsEventStatus_eConsumeNoDefault Thus the assertion happens. So now I am pretty sure the assertion is invalid, it is a possible scenario. A question here is that what the best way to handle the scenario is? An easy way I can think of is to send the INPUT_RESULT_IGNORED state as it is (this is what we are currently doing) then ignore it in the android-component. An alternative way is to let APZ not send the INPUT_RESULT_IGNORED state wait for more touch-move events until APZ escapes from in slop state, and once after APZ escaped from the state, send a proper InputResultDetail to the android-component. I've confirmed locally the former way fixes bug 1852854, but bug 1895742 case is slightly different from the attached test case, in that bug case there's `touch-action: none` style so that INPUT_RESULT_IGNORED should not happen.
While I was diagnosing bug 1895742, I found a test case causing "MOZ_ASSERT_UNREACHABLE: nsEventStatus_eConsumeNoDefault should involve a valid APZHandledResult" (bug 1852854) reliably. Attaching file is the test case, STR is just trying to scroll down not quickly. What's going on there is that 1) there's an active touch-start event listener so that we wait for the result of the event listner 2) when the first touch-move event is received 2-1) the APZEventResult for the touch-move event is initialized with `mHandledResult = Nothing()` since [the target APZ is the root and the event needs to be dispatched to the content](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/gfx/layers/apz/src/APZInputBridge.cpp#37-51) 2-2) we fall into [this if (block->UpdateSlopState(aEvent, consumable) block](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/gfx/layers/apz/src/InputQueue.cpp#201-203), thus the event result becomes nsEventStatus_eConsumeNoDefault Thus the assertion happens. So now I am pretty sure the assertion is invalid, it is a possible scenario. A question here is that what the best way to handle the scenario is? An easy way I can think of is to send the INPUT_RESULT_IGNORED state as it is (this is what we are currently doing) then ignore it in the android-component. An alternative way is to let APZ not send the INPUT_RESULT_IGNORED state wait for more touch-move events until APZ escapes from in slop state, and once after APZ escaped from the state, send a proper InputResultDetail to the android-component. I've confirmed locally the former way fixes bug 1895742, but bug 1895742 case is slightly different from the attached test case, in that bug case there's `touch-action: none` style so that INPUT_RESULT_IGNORED should not happen.