User context ID for <iframe mozbrowser>

RESOLVED FIXED in Firefox 62

Status

()

defect
P2
normal
RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: jryans, Assigned: jryans)

Tracking

(Blocks 1 bug)

unspecified
mozilla62
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62 fixed)

Details

(Whiteboard: [OA])

Attachments

(2 attachments)

The new container tabs feature in Nightly uses an extra origin attribute for user context ID at its core.

Let's bring this same concept to <iframe mozbrowser> so that such frames can also access storage for user context data.  This is needed on desktop for DevTools which uses <iframe mozbrowser> in Responsive Design Mode.

How should we represent the user context on <iframe mozbrowser>?

* @usercontextid (same as <xul:browser>)
* @mozusercontextid
* ...something else?

This ability would only be available to chrome documents.
:tanvi, any suggestions on who from platform could advise about which attribute should be used here?
Flags: needinfo?(tanvi)
Shouldn't the <iframe mozbrowser> inherit the user context from the parent <xul:browser>?
(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #2)
> Shouldn't the <iframe mozbrowser> inherit the user context from the parent
> <xul:browser>?

In the case of RDM, the tab's <xul:browser> is loading a page that displays the UI for the RDM tool, which is a chrome document like many other parts of the browser UI today.  The <iframe mozbrowser> inside that UI document with the content is the first element that would have the user context, so there isn't a parent element to inherit the correct OA from.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #3)
> (In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #2)
> > Shouldn't the <iframe mozbrowser> inherit the user context from the parent
> > <xul:browser>?
> 
> In the case of RDM, the tab's <xul:browser> is loading a page that displays
> the UI for the RDM tool, which is a chrome document like many other parts of
> the browser UI today.  The <iframe mozbrowser> inside that UI document with
> the content is the first element that would have the user context, so there
> isn't a parent element to inherit the correct OA from.

Where woudl you get the usercontext from?  Are you saying that at the point that once the <iframe mozbrowser> is created, it no longer has access to see what the OriginAttributes on the tab's <xul:browser> were?  So you would like to add a usercontextid parameter to <iframe mozbrowser> that is populated on creation?

How do you handle whether the tab is in private browsing mode?

Does the <iframe mozbrowser> make any network requests?

You may be able to solve this problem today by adding a usercontextid into <iframe mozbrowser>, but how will you solve in the future if you have to account for other Origin Attributes?

cc'ing baku and jkt, who may also be able to help.
Flags: needinfo?(tanvi)
Great questions!  Hopefully many answers will help clarify the situation.

(In reply to Tanvi Vyas [:tanvi] from comment #4)
> Where woudl you get the usercontext from?  

I have access to the regular <xul:browser> that we are opening RDM for, so I would read the @usercontextid from this element and copy the same value to the <iframe mozbrowser>.

> Are you saying that at the point
> that once the <iframe mozbrowser> is created, it no longer has access to see
> what the OriginAttributes on the tab's <xul:browser> were?  So you would
> like to add a usercontextid parameter to <iframe mozbrowser> that is
> populated on creation?

Correct, the <iframe mozbrowser> doesn't naturally inherit OriginAttributes from the tab's <xul:browser> because it is not a descendant of the <xul:browser> at creation time.

> How do you handle whether the tab is in private browsing mode?

Since private browsing is a property of the entire browser window (not just one tab), it can be correctly inherited.  nsFrameLoader.cpp already handles[1] retrieving this property and setting PB in the OA for any frame including <iframe mozbrowser>.

> Does the <iframe mozbrowser> make any network requests?

Yes, definitely.  It's used to show content to the user and it's fully interactive like a regular tab, so you can navigate to new pages, load XHR, etc.

> You may be able to solve this problem today by adding a usercontextid into
> <iframe mozbrowser>, but how will you solve in the future if you have to
> account for other Origin Attributes?

I don't think there's a general solution for all OAs, but it would depend on the purpose of each.  If new OA foo is intended to be controlled per tab with a <xul:browser> attribute @foo, then it's likely we'll need the same for <iframe mozbrowser>.  If it's something per window like the PB setting, then it's likely it would be inherited automatically and there's nothing extra to do.

One saving grace is that the `swapFrameLoaders` API (which is used by RDM) ensures that all OAs match between the original content and the <iframe mozbrowser> we're creating.  If they do not match, everything aborts.  So, we should be protected from loading content with _incorrect_ OAs at least.

[1]: https://dxr.mozilla.org/mozilla-central/rev/7452437b3ab571b1d60aed4e973d82a1471f72b2/dom/base/nsFrameLoader.cpp#2175-2179
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #5)
> Great questions!  Hopefully many answers will help clarify the situation.

"Hopefully _my_ answers..."  I guess many answers help too. :)
We currently disable on private browsing anyway so that likely won't be an issue yet. Baku do we really want addons using this feature, I'm not sure if I want (personally) an addon implementing iframes to compare the results across containers. However perhaps we could restrict the feature to chrome only?
Flags: needinfo?(amarchesini)
> I have access to the regular <xul:browser> that we are opening RDM for, so I
> would read the @usercontextid from this element and copy the same value to
> the <iframe mozbrowser>.

we have a similar approach for containers where we set usercontextid attribute to the tab/browser xul element.
So, probably, it _just_ works for you as well.
Important point: you cannot change the userContextId after the first loading.

> > How do you handle whether the tab is in private browsing mode?

userContextId works with private Browsing. You should not have any issue here.
Containers are disabled in private Browsing, but this is just because of the UI of firefox.
No limitation at platform level.

Don't create random userContextId but you should use ContextualIdentityService. Currently this service is not exposed to C++, but it can be easily done.

NI for any questions.
I'm OK to review these patches.
Flags: needinfo?(amarchesini)
Whiteboard: [OA]
Hi J Rryan, looks like this is something that you planned to make it happen in the next release or months, so set P2. Please feel free to change as you see fit.
Flags: needinfo?(jryans)
Priority: -- → P2
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> Hi J Rryan, looks like this is something that you planned to make it happen
> in the next release or months, so set P2. Please feel free to change as you
> see fit.

Yes, either in 52 or soon after, so P2 seems reasonable.
Flags: needinfo?(jryans)
Assignee: nobody → jryans
Status: NEW → ASSIGNED
Comment on attachment 8983873 [details]
Bug 1309735 - Allow usercontextid to be set on mozbrowser frames.

https://reviewboard.mozilla.org/r/249726/#review255920

I would like to review anothe patch containing tests. Test that the segretation happens using any of the following APIs: broadcastchannel, sharedWorkers, localStorage, sessionStorage. Thanks!
Attachment #8983873 - Flags: review?(amarchesini) → review+
Comment on attachment 8983969 [details]
Bug 1309735 - Test container isolation with mozbrowser frames.

https://reviewboard.mozilla.org/r/249822/#review256102
Attachment #8983969 - Flags: review?(amarchesini) → review+
Pushed by jryans@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/db4d4b65e080
Allow usercontextid to be set on mozbrowser frames. r=baku
https://hg.mozilla.org/integration/autoland/rev/a2ccfe2afc9b
Test container isolation with mozbrowser frames. r=baku
https://hg.mozilla.org/mozilla-central/rev/db4d4b65e080
https://hg.mozilla.org/mozilla-central/rev/a2ccfe2afc9b
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.