Bugzilla

It's taken me forever to debug the failure in comment 24, largely because it only seems to occur on very specific builds: ASan and macOS 15 AArch64 Shippable opt Mochitests with networking on socket process enabled test-macosx1500-aarch64-shippable/opt-mochitest-browser-chrome-spi-nw. I eventually realised I was able to reproduce it reliably on my local mac opt build with --verify. For reference, here are some notes from that investigation:

1. This is a race condition. If the test synthesises a key too early, the command is never executed.
2. For keys that aren't reserved, [we must first send them to the content process to see if the content document wants to intercept them. After that, the parent process stops processing the event. The content process then replies, and if the event wasn't prevented by content, it then goes through the parent process event handlers again.](https://searchfox.org/firefox-main/rev/88121de0ccd1a6e364645b9971f36c5eb00f4317/dom/events/GlobalKeyListener.cpp#232)
3. In this case, the content document didn't handle the key. Even so, when the failure occurred, the event never went through the parent process event handlers again.
4. I'm not entirely sure whether the remote process never received the event, chose to prevent default (even though it shouldn't normally do that) or never replied to the event. I didn't dig that far.
5. Originally, I was just calling add_task and running the tests; I never waited for the content document to load. My guess, then, is that the content document wasn't quite ready in the failure case. Maybe the remote document wasn't created yet, maybe it can't handle events at that point in its setup, but I'm really not sure.
6. I've fixed this by just creating a new foreground tab, waiting until it is definitely loaded, running the tests and then removing the tab. This seems to stabilise things locally. Hopefully, it will also behave on CI.

It's taken me forever to debug the failure in comment 24, largely because it only seems to occur on very specific builds: ASan and macOS 15 AArch64 Shippable opt Mochitests with networking on socket process enabled test-macosx1500-aarch64-shippable/opt-mochitest-browser-chrome-spi-nw. I eventually realised I was able to reproduce it reliably on my local mac opt build with --verify. For reference, here are some notes from that investigation:

1. This is a race condition. If the test synthesises a key too early, the command is never executed.
2. For keys that aren't reserved, [we must first send them to the content process to see if the content document wants to intercept them. After that, the parent process stops processing the event. The content process then replies, and if the event wasn't prevented by content, it then goes through the parent process event handlers again.](https://searchfox.org/firefox-main/rev/88121de0ccd1a6e364645b9971f36c5eb00f4317/dom/events/GlobalKeyListener.cpp#232)
3. In this case, the content document didn't handle the key. Even so, when the failure occurred, the event never went through the parent process event handlers again.
4. I'm not entirely sure whether the remote process never received the event, chose to prevent default (even though it shouldn't normally do that) or never replied to the event. I didn't dig that far.
5. Originally, I was just calling add_task and running the tests; I never waited for the content document to load. My guess, then, is that the content document wasn't quite ready in the failure case. Maybe the remote document wasn't created yet, maybe it can't handle events at that point in its setup, but I'm really not sure.
6. I've fixed this by just creating a new foreground tab, waiting until it is definitely loaded, running the tests and then removing the tab. This seems to stabilise things locally. Hopefully, it will also behave on CI.

[Here's the debugging code I used to track this down](https://github.com/jcsteh/firefox/commit/de876a1123dbf78c129a8f7b6272c6ed4db2359b).