Testcase found while fuzzing mozilla-central rev be11d2aa123a (built with: --enable-debug).

Testcase can be reproduced using the following commands:

$ python -m venv venv
$ . ./venv/bin/activate
$ pip install fuzzfetch "git+https://github.com/MozillaSecurity/orion#subdirectory=services/grizzly-android" "git+https://github.com/MozillaSecurity/grizzly@android-rebase"
$ python -m emulator_install &
$ fuzzfetch --os Android --build be11d2aa123a --debug -n firefox
$ python -m grizzly.target.adb_device --prep ./firefox/target.apk
$ python -m grizzly.replay  --platform adb  ./firefox/target.apk testcase.zip

Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Did not assign a type to WidgetMouseEvent in MouseInput), at /widget/InputData.cpp:384

    r10 = 0x0000000000000000	r11 = 0x0000000000000246	r12 = 0x0000727e1db10648
    r13 = 0xaaaaaaaaaaaaaaaa	r14 = 0x0000727e072128a0	r15 = 0x0000727e083e3500
     r8 = 0x00007ffc42dd7080	 r9 = 0x00007ffc42dd70a8	rax = 0x0000727e1a41b5d3
    rbp = 0x0000727e1e9c5ee0	rbx = 0x0000727e1e9c5ef0	rcx = 0x0000727e1e0afd08
    rdi = 0x0000727ea7a49010	rdx = 0x0000000000000002	rip = 0x0000727e15665968
    rsi = 0x0000728107d9fd38	rsp = 0x0000727e1e9c5ea0
    OS|Android|0.0.0 Linux 5.4.86-android11-2-00006-gae78026f427c-ab7595864 #1 SMP PREEMPT Thu Jul 29 20:54:47 UTC 2021 x86_64
    CPU|amd64|family 6 model 6 stepping 3|4
    Crash|SIGSEGV / SEGV_MAPERR|0x0000000000000000|18
    18|0|libxul.so|mozilla::MouseInput::ToWidgetEvent(nsIWidget*) const|hg:hg.mozilla.org/mozilla-central:widget/InputData.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|383|0x1ce
    18|1|libxul.so|mozilla::widget::NPZCSupport::HandleMouseEvent(int, long, int, float, float, int)::{lambda(nsWindow*)#1}::operator()(nsWindow*) const|hg:hg.mozilla.org/mozilla-central:widget/android/nsWindow.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|577|0x4b
    18|2|libxul.so|mozilla::widget::NPZCSupport::InputEvent<mozilla::widget::NPZCSupport::HandleMouseEvent(int, long, int, float, float, int)::{lambda(nsWindow*)#1}>::Run()|hg:hg.mozilla.org/mozilla-central:widget/android/nsWindow.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|249|0xf6
    18|3|libxul.so|nsAppShell::ProcessNextNativeEvent(bool)|hg:hg.mozilla.org/mozilla-central:widget/android/nsAppShell.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|656|0x12e
    18|4|libxul.so|nsBaseAppShell::DoProcessNextNativeEvent(bool)|hg:hg.mozilla.org/mozilla-central:widget/nsBaseAppShell.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|133|0x31
    18|5|libxul.so|nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool)|hg:hg.mozilla.org/mozilla-central:widget/nsBaseAppShell.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|272|0x110
    18|6|libxul.so|{virtual override thunk({offset(-8)}, nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool))}|||0xc
    18|7|libxul.so|nsThread::ProcessNextEvent(bool, bool*)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|1121|0x2d0
    18|8|libxul.so|NS_ProcessNextEvent(nsIThread*, bool)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|465|0x70
    18|9|libxul.so|mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|107|0x10a
    18|10|libxul.so|MessageLoop::RunInternal()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:be11d2aa123af1bff9a001e28fdeec030a1642bb|380|0x5f
    18|11|libxul.so|MessageLoop::Run()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:be11d2aa123af1bff9a001e28fdeec030a1642bb|355|0x4a
    18|12|libxul.so|nsBaseAppShell::Run()|hg:hg.mozilla.org/mozilla-central:widget/nsBaseAppShell.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|150|0x28
    18|13|libxul.so|nsAppStartup::Run()|hg:hg.mozilla.org/mozilla-central:toolkit/components/startup/nsAppStartup.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|295|0x65
    18|14|libxul.so|XREMain::XRE_mainRun()|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsAppRunner.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|5700|0xb1b
    18|15|libxul.so|XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&)|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsAppRunner.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|5894|0x3d7
    18|16|libxul.so|XRE_main(int, char**, mozilla::BootstrapConfig const&)|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsAppRunner.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|5962|0x59
    18|17|libxul.so|GeckoStart|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsAndroidStartup.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|54|0xc8
    18|18|libmozglue.so|Java_org_mozilla_gecko_mozglue_GeckoLoader_nativeRun|hg:hg.mozilla.org/mozilla-central:mozglue/android/APKOpen.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|386|0x21a
    18|19|libart.so||||
    18|20|libart.so||||
    18|21|base.apk!classes2.dex]||||
    18|22|base.apk!classes2.dex]||||
    18|23|libart.so||||
    18|24|libart.so||||
    18|25|libart.so||||
    18|26|base.apk!classes2.dex]||||
    18|27|libart.so||||
    18|28|libxul.so|mozilla::net::SubstitutingURL::EnsureFile()|hg:hg.mozilla.org/mozilla-central:netwerk/protocol/res/SubstitutingProtocolHandler.cpp:be11d2aa123af1bff9a001e28fdeec030a1642bb|71|0x365
    18|29|base.apk!classes2.dex]||||
    18|30|libart.so||||
    18|31|libc.so||||
    18|32|base.apk!classes2.dex]||||
    18|33|libart.so||||
    18|34|base.apk!classes2.dex]||||
    18|35|libart.so||||
    18|36|boot.art]||||
    18|37|libart.so||||
    18|38|libc.so||||
    18|39|libc.so||||
    18|40|libc.so||||
    18|41|libc.so||||
    18|42|libart.so||||

Jed, would you be able to take a look at this and provide your input?

We assert at https://searchfox.org/mozilla-central/source/widget/android/nsWindow.cpp#577 because the mouse event doesn't appear to have a valid type set (https://searchfox.org/mozilla-central/source/widget/InputData.cpp#383-384). We seem to be obtaining this mouse event via IPC (https://searchfox.org/mozilla-central/source/widget/android/nsWindow.cpp#577). It seems possible for SendReceiveMouseInputEvent to fail for various reasons (https://searchfox.org/mozilla-central/source/__GENERATED__/ipc/ipdl/PAPZInputBridgeChild.cpp#136), but APZInputBridgeChild::ReceiveInputEvent (https://searchfox.org/mozilla-central/source/gfx/layers/ipc/APZInputBridgeChild.cpp#90) seems to simply ignore the return value of SendReceiveMouseInputEvent. So since result.GetStatus() might not equal nsEventStatus_eConsumeNoDefault (https://searchfox.org/mozilla-central/source/widget/android/nsWindow.cpp#572-574), we proceed to attempting to convert the input event to a widget event and assert.

Does my reading of this seem reasonable? And which one of the following seems like the right way to address this:

1. Should PAPZInputBridgeChild::SendReceiveMouseInputEvent (https://searchfox.org/mozilla-central/source/__GENERATED__/ipc/ipdl/PAPZInputBridgeChild.cpp#136) be setting aOutResult to something that would indicate an error?
2. Should APZInputBridgeChild::ReceiveInputEvent (https://searchfox.org/mozilla-central/source/gfx/layers/ipc/APZInputBridgeChild.cpp#90) observe the result of the call to PAPZInputBridgeChild::SendReceiveMouseInputEvent and handle a failed call somehow?
3. Should HandleMouseEvent (https://searchfox.org/mozilla-central/source/widget/android/nsWindow.cpp#572-574) skip posting the input event if the mouse input event couldn't be obtained? (This would presumably require number 1 or 2 above as well).
4. Should MouseInput::ToWidgetEvent be changed to not be asserting if mouse input events cannot be obtained successfully via IPC?
5. Should we not do anything, because this assert is correctly pointing at an unexpected situation? I have not traced the rest of the code to make sure that we behave appropriately if the event couldn't be obtained successfully, so if this is the correct path forward we might want to sanity check this.

Bugmon Analysis
Unable to reproduce bug 1780811 using build mozilla-central 20220722085933-be11d2aa123a. Without a baseline, bugmon is unable to analyze this bug.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

(In reply to Stephen A Pohl [:spohl] from comment #2)

2. Should APZInputBridgeChild::ReceiveInputEvent (https://searchfox.org/mozilla-central/source/gfx/layers/ipc/APZInputBridgeChild.cpp#90) observe the result of the call to PAPZInputBridgeChild::SendReceiveMouseInputEvent and handle a failed call somehow?

I think this is where the problem is: the caller of that Send method should be checking the return value, because otherwise the outparams can be invalid. As for what should be done in the error case… I don't think this should be possible unless the sending process is about to shut down or be terminated, so the details probably don't matter much as long as it's safe.

There is an attempt at marking the generated methods nodiscard, but the conditions aren't really right — there's an old idea in this code that the child→parent direction doesn't need to be checked, because the sending process will crash if anything goes wrong, but that may not have been entirely true at the time and definitely doesn't seem to be true today (at least not as an immediate crash). There have been a few changes recently to be more permissive about dropping messages during channel shutdown, which might be related. I'll file a bug about this.

Tentatively moving this to graphics since this lives under gfx/layers/ipc.