Consider immutable mScriptGlobalObject for documents

NEW
Unassigned

Status

()

Core
DOM
12 years ago
8 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

See comments in bug 296639.  Basically, I think that we should never null out
mScriptGlobalObject on documents; the inner window should just be owned by the
document.  Conceivably they should even share a refcount, though that's hard to
do with the cases where we reuse inner windows...
Blocks: 296639
I agree, this should make it possible for documents in the bfcache to be much
more 'alive' (although fiddeling with them too much will get them evicted from
the cache).

What mScriptGlobalObject should documents loaded from xmlhttprequest and the
likes get? The same as the 'owner document' or a new one?
That's a good question.  What script global and container, if any, should those
get?  Right now, loading via XMLHttpRequest sets no container or script global,
iirc.  Creating via DOMImplementation sets a container but no script global.

I'd say documents not attached to a window should have no container (which is
basically the docshell/outer_window) and documents that don't plan to run
scripts or dispatch events should have no script global.

So do we ever run scripts or dispatch mutation events or whatnot in such
documents?  Should we?
(In reply to comment #2)
> So do we ever run scripts or dispatch mutation events or whatnot in such
> documents?  Should we?

Bug 201236 for mutation events; I plan on dispatching events if they have a
mutation event listener, even if they lack a window.
*** Bug 308902 has been marked as a duplicate of this bug. ***
Blocks: 322726
Assignee: general → nobody
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.