Open Bug 293175 Opened 20 years ago Updated 2 years ago

Inconsistent document container handling

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86
Linux
defect

Tracking

()

mozilla1.8beta4

People

(Reporter: bzbarsky, Unassigned)

References

Details

(Whiteboard: [ETA ?])

Before bfcache we had the invariant that a document's container was immutable after document creation and was the docshell the document was in. With bfcache, this is still true _except_ for bfcached documents, which have a null container. Should there really be a difference here between bfcache documents and other documents that have been navigated away from? That seems wrong to me. We should probably unset the container consistently, and make sure document teardown still works right... Also, should documents created via DOMImplementation really have a container set? That seems wrong to me.
I agree, but this is a separate issue from bfcache. Unmarking dependency to get it off the radar.
No longer blocks: blazinglyfastback
Er... We have an invariant that code may be depending on and that bfcache violates. Until we check that all code that uses this container deals with it being null and that for a bfcached document this leads to the right behavior, this is in fact a bfcache issue. If such checking has already been done, then my apologies; let me know and I'll remove the dependency in that case.
pulling into beta for investigation
Target Milestone: --- → mozilla1.8beta4
Flags: blocking1.8b4+
Assignee: general → bryner
Whiteboard: [ETA ?]
Flags: blocking1.8b5+
Flags: blocking1.8b5+
bryner, have you had a chance to look into this?
bryner's busy with other bug fixing. Who else could help here?
peterv, maybe? /be
We're not getting anywhere here. Who else can help? Johnny, Bryner, any ideas here? Time is running out.
Without an actual example of somebody relying on this former invariant, we're not going to block on this.
Flags: blocking1.8b5+ → blocking1.8b5-
Anyone calling GetScriptGlobalObject() is relying on it.
Calling it after nsDocument::Destroy, that is.
But do we have an case of that happening in-tree or in common extensionland?
We have at least some known in-tree cases; they're already covered by separate bugs (eg XTF has this issue at document teardown). I have no idea about extensions. The whole point of this bug was to either fix the issue or to check that our in-tree consumers are OK with this. Since the latter hasn't happened, I can't tell you whether they're OK or not, clearly.
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.9-
I think all of the issues we know about here have been addressed.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Quick check turns up XBL code that definitely calls GetScriptGlobalObject() in cases when bfcache has nulled out the container (so whatever that code is trying to do doesn't work). We do have a separate bug on that, but it sure isn't fixed... Given that, I doubt that the code-reading that needs to happen here has been done.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reassigning my bugs, since I'm not actually working on them.
Assignee: bryner → nobody
Status: REOPENED → NEW
QA Contact: ian → general
Component: DOM: Core → DOM: Core & HTML
Priority: -- → P5

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.