Closed Bug 1585066 Opened 5 years ago Closed 4 years ago

Audit usage of nsIDocShellTreeItem in MaybeDowngradePrincipal

Categories

(Core :: DOM: Navigation, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1642425

People

(Reporter: djvj, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [rm-docshell-tree-item:sync-state])

https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/dom/base/Document.cpp#2561

Called (two levels deep) from Document::StartDocumentLoad. This queries the principal of the parent document for whether it's a system principal. If the parent is NOT a system principal, then the a downgraded principal is returned.

This seems like a good candidate for a flag on the BrowsingContext. Knowing whether your parent document (or some ancestor) has the system principal or not should not be sensitive.

Fission Milestone: --- → M5
Priority: -- → P2
Depends on: 1587436
Whiteboard: [rm-docshell-tree-item:sync-state]
Fission Milestone: M5 → Future

Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).

Fission Milestone: Future → M6

We can probably get away without synced state here, by always downgrading the principal from the system principal to a null principal if we're in a cross-process subframe case. I'm not sure if we ever have system principal documents loaded in content processes.

The current behaviour here definitely seems less than optimal, as we'll conclude that it's OK to load a chrome document if the loading docshell happens to be the root docshell within a content process.

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

Summary: Fix usage of nsIDocShellTreeItem in MaybeDowngradePrincipal → Audit usage of nsIDocShellTreeItem in MaybeDowngradePrincipal

Auditing whether this use of nsIDocShellTreeItem breaks when Fission is enabled blocks Fission Nightly.

Fission Milestone: M6 → M6b
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Clearing Fission Milestone for bugs resolved as duplicates. We don't need to track duplicates.

Fission Milestone: M6b → ---
You need to log in before you can comment on or make changes to this bug.