Replace uses of nsIDocShellTreeItem with BrowsingContext
Categories
(Core :: DOM: Core & HTML, enhancement, P3)
Tracking
()
Fission Milestone | Future |
People
(Reporter: relaas, Unassigned)
References
(Depends on 6 open bugs, Blocks 2 open bugs)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Just wondering we do already have a way to enumerate OOP child subdocuments in a document? I believe it's necessary for bug 1519546 and bug 1518919 at least. I thought this is the bug to provide the way, but boris told me on IRC that this bug is fission:M3 and bug 1519546 is fission:M2.
Nika?
Comment 4•6 years ago
|
||
You can enumerate the BrowsingContext
s which are children of the current document's BrowsingContext
. If those have a nsDocShell attached to them, they're in-process, and otherwise they're out-of-process.
In bug 1525427 I've also added a method to get the embedder <iframe> element for one of these BrowsingContext elements, which can be useful for getting any other relevant information here.
Is that sufficient, or is there something else you need?
Comment 5•6 years ago
|
||
Thank you, Nika! Yes, it sounds sufficient for the purpose.
Updated•6 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Partial, draft assessment of uses of nsIDocShellTreeItem and semantic notes.
Comment 7•5 years ago
|
||
Ok, I'm going to change my approach here. Auditing the entire list is going really slow, and I don't think I should block the next step until this completes. It's unnecessary serialization.
I think I'll take what I have now, and start spinning off bugs for individual files to fix up. This will at least open the possibility of others starting on some of this work while the audit is still ongoing, and I can create new bugs as I audit more stuff.
Nika, what do you think?
Comment 8•5 years ago
|
||
(In reply to Kannan Vijayan [:djvj] from comment #7)
Ok, I'm going to change my approach here. Auditing the entire list is going really slow, and I don't think I should block the next step until this completes. It's unnecessary serialization.
I think I'll take what I have now, and start spinning off bugs for individual files to fix up. This will at least open the possibility of others starting on some of this work while the audit is still ongoing, and I can create new bugs as I audit more stuff.
Nika, what do you think?
Sounds like a solid plan!
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Description
•