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.
Tracking this with CHROME_MODAL is problematic, because that gets inherited by
any dependent windows opened by the modal content window, which may or may not
be modal content windows themselves. Thankfully, we have a few free bits lying
around.
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.
Tracking this with CHROME_MODAL is problematic, because that gets inherited by
any dependent windows opened by the modal content window, which may or may not
be modal content windows themselves. Thankfully, we have a few free bits lying
around.
We don't test with MOZ_MEDIA=0 so that configuration no longer
works. It's better to drop the switch altogether and enable
this code unconditionally. Per-codec and -feature configure
and runtime options remain available.
dom/interfaces/svg/Makefile.in and dom/media/Makefile.in had merge
conflicts. They were resolved by hand. The former needed 2 IDLs removed.
The latter had a context conflict for EXPORTS_NAMESPACES.
XPIDL_MODULE defaults to MODULE. These Makefile.in were setting
XPIDL_MODULE to the same value as MODULE.
--HG--
extra : rebase_source : e96bd34d5949d0ab94cecbec35d6c9f4bffec01e
