1239408 - Audit nsFrameLoader / TabParent for mozbrowser frames on desktop

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

:billm, who would be able to do such an audit?

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.