This morning I think I’ll read over what happens when you call alert(), confirm(), or prompt() in JavaScript. Because the next Odysseus “trait” on my list renders the UI for that, without blocking your interaction with other tabs.
Inevitably this’ll probably do little more than send the message out of the sandbox for Odysseus to handle, but how does it freeze the page until it gets a response?
The first layer after translation of that call to C++ blocks the dialog from showing on unload or in sandboxed iframes. They don’t show on unload because that slows down WebKit’s (highly convenient) tab history optimizations, and I’ll cover “do you wish to leave this page?” confirms later as they don’t seem to hit this codepath.
The next layer with the “Page” defers onload events, notifies any spin buttons (so it can release it’s grabs), and possibly rewrites “" to “$”.
Then as it leaves the sandbox, WebKit checks if it’s on a blank page which shouldn’t be opening dialogs, notifies any in-sandbox extensions, and disables the watchdog timer. And in sending the message it immediately begins waiting synchronously on a reply, still accessibility messages through.
Outside the sandbox it will close any fullscreen views on iOS, stop any responsiveness timers there, and notify any automated testing.
THIS IS THE KEY STEP!
That then passes it to a “UI client” which (for the GTK port) does nothing more than translates the C++ into GObject C.
The GTK embedding widget will then translate them all the dialogs into a common GObject representation, which’ll call a callback on close, before triggering the “signal” I handle.
That callback in turn comes from the autogenerated IPC code to end the sandbox’s wait.
The signal by default opens a modal window, but Odysseus overwrites that with an “Info Box” (which btw requires a bit of assembly to use). And it had to tell the WebView to stop handling events and queueing them up for after the info box is closed.