1643740 - use userContextId in GeckoView

Status: NEW

(GeckoView :: Extensions, defect, P3)

Description

[[ex-Mozilla] Agi Sferro | :agi]

There are a few places in the web extension implementation where we use userContextId but on GV we use geckoViewSessionContextId, we should fix that.

See Bug 1643688 for context.

Comment 1

[[ex-Mozilla] Agi Sferro | :agi]

So after some discussion with various people (including :snorp and :robwu) a while back we are thinking to actually make GeckoView use userContextId and move some desktop-specific logic from toolkit to browser (e.g. the list of predetermined containers shouldn't live in toolkit). Morphing this bug to that.

Comment 2

[Ankush Dua]

Hi, I would love to work on this issue but unfortunately, the explanation provided in the description of bug 1643688 and in this comment was not very clear to me.
Could you please guide me on what needs to be done on this issue specifically?

Comment 3

[[ex-Mozilla] Agi Sferro | :agi]

Hi there! This is a little involved so I would definitely fix other, smaller and easier bugs before tackling this one.

To give an overview:

• userContextId is used internally in Gecko to tag a tab with a "container" id. Many places in Gecko use this ID, among which the extension API, cookie jar, etc.
• However, GeckoView doesn't use this ID, and instead uses geckoViewSessionContextId, mostly for historical reasons. Gecko has some front-end specific code around userContextId, and instead of refactoring that we decided to create our own field.
• In hindsight, having our own fields has a lot of drawbacks: we can't use a lot of the existing code around userContextId, we need to special case mobile a lot etc.
• So what we decided to do is to instead do the refactor, moving all the UI-related bits from toolkit (platform-independent code) to browser (Firefox Desktop specific)

To do this we need to:

• Move https://searchfox.org/mozilla-central/rev/a0ccd492719b1ad2106f6456549be62a76f45acb/toolkit/components/contextualidentity/ContextualIdentityService.jsm to browser, GeckoView apps like Fenix will manage the container store (since most of it is UI-related anyway) so creating/listing/deleting a container needs to be done in the app. Not sure exactly how the desktop side will handle it but GeckoView could have its own ContextualIdentityService that allows Gecko to deal with containers (forwarding the request to the app using a Delegate) and Desktop can have the current one in browser.
• (*) Cleanup all code that today uses ContextualIdentityService and make sure that the GV code path works too.

(*) is, of course, a lot of work as there's probably a lot of code that relies on exactly the inner-workings of ContextualIdentityService.

I'm definitely available for mentoring on this, but again, let's fix some simpler stuff first :)

Comment 4

[Ankush Dua]

For Sure!... Do you have any recommendations for simpler issues related to this or in general, through which I can learn more about the platform?

Comment 5

[[ex-Mozilla] Agi Sferro | :agi]

Hey Ankush! Thanks for your interest. I think Bug 1651506 is a good one to practice a little bit. Rob has added some details already but feel free to drop in https://chat.mozilla.org/#/room/#geckoview:mozilla.org if you have further questions.

Comment 6

[karim]

Hey!

I've been familiarizing myself with the codebase, and I think I am able to tackle this bug.

Comment 7

[[:owlish] 🦉 PST]

still relevant