Audit nsIDocShellTreeItem usage in nsFrameLoader::AttributeChanged in dom/base/nsFrameLoader.cpp
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
Fission Milestone | Future |
People
(Reporter: djvj, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [rm-docshell-tree-item:hard])
In file dom/base/nsFrameLoader.cpp
Gets parent, checks ItemType for Chrome, and checks parent owner for existence.
Removes and re-adds the parent tree item from the parent tree owner.
Since this involves the tree-owner, and that needs to go away, this code will likely change to use TabContext, BrowsingContext, etc. as appropriate in the new semantics.
No easy bug for this, this relates to an architecture and design issue.
Comment 1•5 years ago
|
||
Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).
Updated•5 years ago
|
Comment 2•4 years ago
|
||
We need to audit this use of the nsIDocShellTreeItem interface. With Fission enabled, Documents and nsDocShells for related frames, such as subframes and parent documents, may not be available within the current process and the corresponding nsIDocShellTreeItem methods will return null.
If this code is broken with Fission, fixing it blocks enabling Fission is Nightly.
If this code works as-is with Fission, we don't need to remove this usage of nsIDocShellTreeItem until when we remove nsIDocShellTreeItem entirely (bug 1607591) after we ship Fission MVP.
Fission documentation about replacing nsIDocShellTree Item:
https://wiki.mozilla.org/Project_Fission/DocShell_Tree_Replace
:farre's presentation with examples of replacing nsIDocShellTreeItem with BrowsingContext, WindowContext, SyncedContexts, and BrowsingContextGroup:
https://docs.google.com/presentation/d/1K4j6ngty64TZjJNS5qH-MBoOm3TI2dJedVsbH8jUhKE/edit#slide=id.g6e35225e5d_1_264
Comment 3•4 years ago
|
||
Auditing whether this use of nsIDocShellTreeItem breaks when Fission is enabled blocks Fission Nightly.
Updated•4 years ago
|
Updated•2 years ago
|
Description
•