It's not my fault that I keep finding problems both with patches themselves (see XHR problem) and tests (see above and !4312 earlier). I think that you too easily ignore signs of problems with tests. Given current findings, for all we know, native may have similar problems of using non-owned references. Your claims that it's one and the only right solution is simply not backed by convincing arguments.
I'm not saying it's the perfect or right solution, and I doubt we care about reproducing crashes like native does (right?). It is, however, more correct than what we have, because *at least* one extra test passes. Isn't that the point? It's not like I can write a perfect Windows implementation in one patch. And of course I'd be happy to change it as long as the test still passes.
This isn't like I'm refusing to change my patches in any way, as long as the tests will still pass. You haven't suggested an alternative other than just saying you don't find it worth it (despite the failing test currently).
Note that we hide a lot of complexity behind Gecko, but native complexity surely needs more complex data structures, just like Gecko does. It means that we can't blindly extrapolate `get_parentWindow` test result to all outer_window use cases.
I don't mean to extrapolate anything. I specifically made it so that all other usages of the outer window from the inner are **same as before except** for the stuff I tested. This includes get_parentWindow, storage events, and the omHistory. But that's it. What was not tested **I made sure it kept previous behavior** (and if I didn't, it was a mistake, not intentional, so I was hoping for a review on it so I can fix it, that's what I wanted…).
What is so wrong with this? I'm not assuming anything here.
The big picture is that inner window is not the same thing as the outer window and pretending that inner window becomes another inner window after navigation (when `inner_window->outer_window->inner_window != inner_window`) is likely a sign of a problem. The fact that your message source implementation depends on it is worrying, for example.
Why is that so strange? Even according to [MDN](https://developer.mozilla.org/en-US/docs/Glossary/WindowProxy), the underlying "window" changes on navigation, despite the same object being used to access it (outer window -> new inner window). Isn't that the point?
I'd hope that you'd know the answer before signing off patches like this (or !4312 for that matter).
But I wasn't necessarily looking into fixing *that* (it's only after I tested them that I tried to fix it), ergo it shouldn't have changed its behavior. But if I test it, I doubt that be enough of an argument anyway, so it's a bit frustrating wasting time for no reason.
EDIT: BTW please let's just ignore the storage events for now; not because it doesn't matter but because it still fixes the case without JS, and it's absolutely not anything more complex to implement *as long as* the patch with outer window exists. If it doesn't, then the code will be the same (literally) just different behavior, so I don't think that should be an argument *against* the patch at the very least (even if it's not an argument *for* the patch).