mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
c3882ecf88
wantXrays means that the sandbox wants Xray wrappers even when accessing same- origin content. The default is true, which Blake says has something to do with GreaseMonkey and days of old. This flag never had an effect for chrome, because the chrome->chrome case always short-circuited to &CrossCompartmentWrapper::singleton. But once we start respecting the flag as a general-purpose indicator that Xrays should be applied same-origin, we need to either add a special case in Rewrap or make the flag reflect reality. The latter seems cleaner and more sane. However, things are complicated by the fact that there's also a completely different, orthogonal usage, whereby setting wantXrays to false implicitly waives Xray on the returned sandbox _and_ on any results returned from evalInSandbox. This is just nuts. The former can be accomplished by callers manually using .wrappedJSObject, and the latter by having EvalInSandbox transitively apply waivers from their sandbox arguments. I've updated the documentation on the MDN page so that it only describes the reasonable usage. The next step is to get rid of the crazy behavior. I think the best path of migration is to have wantXrays: false keep implicitly waiving, but waive return values from EvalInSandbox based on whether the argument was waived. This patch does that. |
||
|---|---|---|
| .. | ||
| ductwork/debugger | ||
| examples | ||
| ipc | ||
| jsd | ||
| public | ||
| src | ||
| xpconnect | ||