mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
ed9547ed3d
Boris and I debugged this. It looks like we're somehow ending up with an XrayWaiver on the other end of a CrossOriginXrayWrapper. The specifics of how this happens are a bit fuzzy to me, but it's presumably happening in all the brain transplant weirdness we do when recomputing wrappers during document.domain. Having an XrayWaiver there isn't unsafe - the wrapper computation algorithm will ignore the waiver if the principals don't allow the caller to waive. But it does throw a wrench in some brittle code that only expects certain kinds of wrappers. Let's just do what XrayTraits::getTargetObject does. I don't think this is really unsafe at all, because the only wrapper with a security boundary is the CCW, and we're already stripping that off unconditionally with Wrapper::wrappedObject. |
||
|---|---|---|
| .. | ||
| AccessCheck.cpp | ||
| AccessCheck.h | ||
| AddonWrapper.cpp | ||
| AddonWrapper.h | ||
| ChromeObjectWrapper.cpp | ||
| ChromeObjectWrapper.h | ||
| FilteringWrapper.cpp | ||
| FilteringWrapper.h | ||
| moz.build | ||
| WaiveXrayWrapper.cpp | ||
| WaiveXrayWrapper.h | ||
| WrapperFactory.cpp | ||
| WrapperFactory.h | ||
| XrayWrapper.cpp | ||
| XrayWrapper.h | ||