If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Audit nsFrameLoader / TabParent for mozbrowser frames on desktop

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: jryans, Assigned: jryans)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

In bug 1238160, we are exploring allowing mozbrowser frames (or something similar) to be used as an alternative to <xul:browser> on desktop.

billm says someone should audit the frameloader/TabParent code to make sure everything works the way we expect on e10s.
(Assignee)

Comment 1

2 years ago
:billm, who would be able to do such an audit?
Flags: needinfo?(wmccloskey)
I think it would be fine for you to do it as long as you understand the meaning of all the TabContext stuff. That's mostly what I'm worried about.
Flags: needinfo?(wmccloskey)
(Assignee)

Comment 3

2 years ago
I've completed my audit of the code paths surrounding nsFrameLoader and TabContext.  I also investigated various Principal, DocShell, and TabContext APIs related to whether things are browser elements, apps, and what their OriginAttributes are, as these are all related to the "non-isolated" <iframe mozbrowser> mode discussed in bug 1238160.

The audit has my notes on all these APIs:

https://docs.google.com/document/d/1rHVOFhDtko8adpgXxaPvYs6qhAEIdvARVuciVDnKIbk/edit

For enabling <iframe mozbrowser> as it is today, I found no issues on the desktop side, so I'll proceed with enabling that plus tests to ensure it's not exposed to content.

As for the new non-isolated mode, there are various changes needed across various APIs.  I'll describe my plan for this in more detail in bug 1238160.
Assignee: nobody → jryans
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.