Closed Bug 716004 Opened 13 years ago Closed 13 years ago

Traverse nsXBLDocumentInfo less often

Categories

(Core :: XBL, defect)

12 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached patch patch (deleted) — Splinter Review
Keep similar behavior to rest of DOM to traverse script objects, but don't traverse anything else. If mDocument is in generation, so is then nsXBLDocumentInfo (owned by xul cache).
Attachment #586508 - Flags: review?(continuation)
Is there some specific reason you are concerned about moving around script traversal or are you just being safe? The code looks fine to me, but I don't know anything about nsXBLDocumentInfo, so you should get somebody else to confirm that mDocument always holds the nsXBLDocumentInfo alive.
OS: Linux → All
Hardware: x86_64 → All
Attachment #586508 - Flags: review?(continuation) → review+
I talked to jst about this a little, and he said that these objects aren't guaranteed to be in the XUL cache. Or rather, they are in the browser as is, but somebody could configure non-browser usage (or something like that?) so they wouldn't be.
Blocks: 698919
Summary: Traverse XBL even less → Traverse nsXBLDocumentInfo less often
The objects are in XUL cache if they are in CC generation. This relies on the behavior of https://bugzilla.mozilla.org/show_bug.cgi?id=713865.
Ah, yes, that makes sense.
Is that true even for non-chrome XBL documents? I.e. if a user explicitly enables remote XBL for a given site?
If those aren't in XUL cache, document's aren't marked to be in CC generation.
...see the patch for bug 713865.
Good point.
Attachment #586508 - Flags: review?(jst)
Blocks: 716598
No longer blocks: 698919
Attachment #586508 - Flags: review?(jst) → review+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: