Injected scripts cause infinite loop at https://treasure21.timotijhof.net/ducks.html

[Krinkle]

Steps to reproduce

1. Firefox 192.2 (44469)
2. Open https://treasure21.timotijhof.net/ducks.html
3. Click "First clue" and type "spg".

Expected behavior

The input element is removed, and a new input field is inserted and focused.

https://github.com/Krinkle/treasure21/blob/f002bff681cd49d763b47d2b1af5e8e6e2095ae4/public_html/src/ducks.js#L64-L77

Actual behavior

Once the new input is focused, the browser freezes.

Device & build information

• Device: iPhone SE2

Notes

The issue does not happen in:

• Safari on macOS.
• Chrome on macOS.
• Firefox on macOS.
• Mobile Safari on iOS.

It appears specific to Firefox on iOS.

I've debugged this over USB in Safari Web Inspector on macOS and noticed that the dirInputNode.focus(); call (reached once the third character "g" has been entered) goes in to a dozen "Extra Scripts" injected by the firefox-ios app, including various focus and focusin handlers.

What I know:

• When reproducing this without inspector attached, the app freezes.
• When reproducing this with inspector attached, the app freezes,
• When reproducing this, and breaking above dirInputNode.focus();, and setting dirInputNode.focus = function() {}, to effectively skip it and any extra scripts listening to focus/focusin, the app does not freeze.
• When reproducing this, and setting various breakpoints in the extra scripts, and stepping in and out of a few, and then resuming, the app does not freeze. Suggesting there's some kind of async, setTimeout, or postMessage logic in Firefox's content scripts creating a race condition where if you run it slow enough, the code doesn't crash.
• When reproducing this, and breaking above dirInputNode.focus();, and then disabling breakpoints and resuming, the app freezes. Suggesting that it isn't due to a race condition in my own code.

┆Issue is synchronized with this Jira Task

[Krinkle]

When the app freezes, there isn't an obvious way to close or reload the tab, and it doesn't respond the "pause" or "reload" buttons from the attached the Safari Web Inspector, either.

However, if you minimise the app and switch to another app for about 5-10 seconds, it will eventually force quit that one tab on its own, and when you switch back, it'll reload that tab. As such, you don't lose your other tabs. It's still a pretty jarring and counter-intuitive experience, though. I was expecting the tab switcher or address bar to still work regardless of some kind of content script misbehaving. And, while I haven't verified this, I suspect if the crash happend on page load, I'd have no way to get out of the loop (short of using Airplane Mode, quiting the app, and then waiting long enough for it to not resume or reload from cache, and then re-opening it and that time closing the problematic app). Perhaps that could use some improvement separately from this bug, such that "mere mortals" can also rid themselves of a crashed tab.