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.
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.
While the mArguments invariant should hold for _outers_, it doesn't necessarily
hold for inners, so this assertion fires reliably in automation. If mCleanedUp
is true then mArguments is definitely null, so let's disentangle this from
mArguments and be clearer about the invariants we expect.
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.
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.
While the mArguments invariant should hold for _outers_, it doesn't necessarily
hold for inners, so this assertion fires reliably in automation. If mCleanedUp
is true then mArguments is definitely null, so let's disentangle this from
mArguments and be clearer about the invariants we expect.
I can't see what this is supposed to be doing. The one caller defaults to aCx,
and if not, gets and pushes a context associated with the document, restoring
it to the default compartment.
So this only changes the behavior when we use the aCx that comes in from above,
in which case it's totally not clear to me why we would want to get the default
global here.
Edgar Chen
Boris Zbarsky
Ryan VanderMeulen
Ms2ger
Masatoshi Kimura
Andrea Marchesini
John Daggett
Ed Morley
Mike Shal
David Zbarsky
Bobby Holley
Andrew McCreight
Jan-Ivar Bruaroey
Tim Abraldes
Phil Ringnalda
Michael Harrison
Mitchell Mebane
Alive Kuo
Terrence Cole
Luke Wagner
Colby Russell
Sankha Narayan Guria
Tim Taubert
Fabrice Desré
Mihai Sucan
Jim Blandy
Kevin Grandon
Andreas Gal
Ted Mielczarek
Aryeh Gregor