After talking to jlebar it appears that TabParent.h will be providing both appID (via GetApp().GetLocalId) and InBrowser (via IsBrowserElement) once bug 802366 lands. We should 1) make TabParent also provide per-tab PB mode info (jdm tells me there's a 1-1 mapping: not clear if we need to dynamically update the TabParent with PB mode if it changes over time, or if it stays constant for TabParent lifetime), and 2) rip out all the steaming garbage (nsIPrivateBrowsingChannel, etc) that we've added to support PB mode on top of SerializedLoadContext 3) Probably remove all the IPC loadcontext stuff entirely. These 3 fields are all we're using it for, and we can't trust the values the child passes anyway. This is probably more than one bug--let's make this the tracking bug. jdm, can you let me know if #1 is feasible and open a bug for it if so?
On further thought, for non-e10s we still need nsILoadContext (and for now at least, nsIPrivateBrowsingChannel overrides). But we can still aim toward getting rid of SerializedLoadContext and LoadContext.h/.cpp (i.e. the goop we currently use to get nsILoadContext on the parent), and instead have TabParent implement nsILoadContext. It's got two of the three needed fields--all we need in usePrivateBrowsing.
Summary: e10s: stop using LoadContext for appID/inBrowser/PrivateBrowsing → make TabParent implement nsILoadContext
I think this is moot now that we're not going to pass TabParent around in IPDL calls in necko e10s.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.