Historically, we've had a bunch of complicated machinery to delay the call to
CleanUp() for modal dialogs, since we needed to harvest the return value after
the window closed. But in the current world we don't actually null out
mReturnValue in CleanUp() at all, which presumably happened sometime around the
time mReturnValue became cycle-collected. So this stuff can just go away. \o/
That simplification is righteous in itself. But it also fixes the bug here as-
filed. When the user quits while a modal dialog is currently being displayed,
a failure code ends up bubbling up through windowWatcher to the OpenInternal call
in nsGlobalWindow::ShowModalDialog, which means that we're unable to do our
delayed CleanUp() call for the outer modal window. At first it seemed like a hard
problem to solve, but with the above it becomes trivial.
There are still a handful that either are used with other runtimes, or that
happen very early/late in cx the lifetime of various things where it doesn't
necessarily make sense to have a cx on the stack. This should definitely ensure
that we're not doing double-duty with the nsCxPusher change, though.
The main idea behind this thing seems to be that we don't want script to quickly
close the window before the user has time to read the notification. Given the
fuzziness of the constraint here, I think we can (and maybe even should) unblock
a little bit later in the event loop, rather than immediately after the script
terminates.
Note that, due to modal dialogs and their event loop spinning shenanigans, we
want to do this only when the stack frame is popped.
Since this stuff is a property on the browsing context, this only makes sense
as a security check. But now that we're using a DialogValueHolder, the origin
checks are taken care of. So we can kill this off.
The spec currently has returnValue as a DOMString, but this doesn't match
reality given my testing. I filed [1] to fix it.
Note that nsGlobalModalWindow is already set up to CC mReturnValue. Since
we're swapping in another CC-ed container class, we don't need to make any
changes here.
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21771
This is correct by my reading of the spec. Quoting:
The dialogArguments IDL attribute, on getting, must check whether its browsing
context's active document's origin is the same as the dialog arguments' origin.
If it is, then the browsing context's dialog arguments must be returned
unchanged. Otherwise, if the dialog arguments are an object, then the empty
string must be returned, and if the dialog arguments are not an object, then
the stringification of the dialog arguments must be returned.
