Crash in /html/browsers/the-window-object/self-et-al.window.html #28298
Comments
jdm
added
I-panic
|
That tests that the window proxy's self references— There's two variants. The first with an iframe that's removed from the DOM; the second with a closed window. The For the iframe, Edit to add: ...but that's a bad guess! I need to learn a bit about constellations, how Servo manages the window proxy. |
|
It would be useful to narrow down the testcase to the smallest set of elements and JS that can trigger the crash. |
|
Here's a reduced test case for <!DOCTYPE html>
<body>
<script>
'use strict';
const f = document.body.appendChild(document.createElement('iframe'));
const w = f.contentWindow;
f.remove();
requestAnimationFrame(() => {
console.log(w.frames === w ? 'PASS' : 'FAIL');
});
</script>This should log "PASS", instead it panics in the |
|
I've been reading bindings a bit. High level, these getters thunk through the window proxy so presumably the window proxy could return self for these getters. (This what Chrome does although the details are a bit convoluted.) Simply not clearing the window proxy in Window.clear_js_runtime fixes the problem but I'm not sure if that compromises security or correctness around navigation. Superficially the following things are surprising:
|
|
I think the key to this is found in the spec:
In particular, note the "and that browsing context's WindowProxy is eligible for garbage collection". Instead, in HTMLIFrameElement::unbind_from_tree, we assume the BC can be removed, even though in this case the window is still reachable by script(but he document is gone?) The solution I think is not simple, one would have to keep track of windows after iframes are unbound from the tree, and only send the Perhaps a simple first solution is to only remove the BC of an iframe when the associated TOP level BC is closed. So basically leak the window of iframes somwhere on |
The text was updated successfully, but these errors were encountered: