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.
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 patch is bigger than I'd like it to be, but there are a lot of interlocked
dependencies and I eventually decided it was easier to just lump it together.
The semantics of |showModalDialog|/|window.dialogArguments| (an web-exposed
HTML5 feature) and |openDialog|/|window.arguments| (a XUL-proprietary feature)
are quite different. The former is essentially a security-checked JSVal, while
the latter gets converted into an array. We handled them together in the old
world, which led to a lot of confusion and muddled semantics. This patch
separates them.
This patch also eschews the roundabout resolve hook for dialogArguments in favor
of returning them directly from the XPIDL getter. This better matches the
behavior in the spec, especially because it allows dialogArguments to live on
the outer as they're supposed to, rather than the first inner that happens to
end up in the docshell. All in all, this should make this all very
straightforward to convert WebIDL when the time comes.
The current spec on the origin checks here is pretty fictional, so I've filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21932 to fix it. This patch
should more or less preserve the current security behavior.
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.
