746204 - DOMApplicationRegistry should support Persona switching

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Anant Narayanan [:anant]]

DOMApplicationRegistry is a singleton that puts all apps into a single list, regardless of which persona the user was signed into when an app is installed. We should make sure apps installed as different personas are separated appropriately.

Comment 1

[Jason Smith [:jsmith]]

Anant - Is this blocking bug 754538's completion, since this is needed to support cases where a user uses multiple personas? It's also a AITC requirement generally, correct? If so, can you nominate this for k9o?

Comment 2

[Jason Smith [:jsmith]]

Nominating for k9o - required to manage apps across multiple BID accounts in a single FF profile for AITC

Comment 3

[Bill Walker [:bwalker] [@wfwalker]]

Dan, can you please comment on this from a product requirements point of view?

Comment 4

[Dan Mills [:thunder]]

I'm afraid I don't quite understand this bug/feature, can someone explain what it's about at a higher level?

I'm available to chat f2f if that's better.

Comment 5

[Anant Narayanan [:anant]]

(In reply to Dan Mills [:thunder] from comment #4)

Dan, this bug is about supporting different users (as identified by their Persona) to install apps within the same firefox profile (and have them be segregated). We were hoping to rely on SITB to implement this at some point.

Comment 6

[Anant Narayanan [:anant]]

This may really be a question for Jen / Ragavan, do we want to support users A and B installing apps in the same firefox profile and have them show up on their individual dashboards instead of piling all apps installed in a single firefox profile into a single bucket?

If so, do we need to support this before sign in to the browser is implemented?

Comment 7

[Jason Smith [:jsmith]]

A followup on comment 6 - the current state of the world says the registry we track these apps in does not take the persona the app is installed with into account, so see the blocker bugs to understand the risks that can cause without implementing this.

Comment 8

[Dan Mills [:thunder]]

I think all apps should end up on the same dashboard. Ragavan/Jen?

Comment 9

[Jason Smith [:jsmith]]

(In reply to Dan Mills [:thunder] from comment #8)
> I think all apps should end up on the same dashboard. Ragavan/Jen?

All apps regardless of the persona account? Meaning could we have cases such as:

Dashboard

- 3 apps with persona account #1
- 4 apps with persona account #2
- 7 apps with persona account #3

If so, then there's a bunch of use cases to watch out, such as:

- Persona account conflicts for apps (same app on 2 accounts)?
- Deletion of an app locally - does this still imply deletion from AITC?

If something like that gets considered, then we may need to separate the concept of the apps stored in the dom registry vs. apps that are stored in the cloud and the interactions associated with each.

Comment 10

[Dan Mills [:thunder]]

App receipts are not currently tied to identities, so while you may have installed apps while signed into the marketplace with different email addresses, the receipts you get at the end aren't tied to those addresses.

So I don't see any conflict possible: you can't have the same app twice, and a dashboard syncs to only one AITC service.

Real/better multiuser support requires sign into the browser support. I think that's okay.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Dan Mills [:thunder] from comment #10)
> App receipts are not currently tied to identities, so while you may have
> installed apps while signed into the marketplace with different email
> addresses, the receipts you get at the end aren't tied to those addresses.
> 
> So I don't see any conflict possible: you can't have the same app twice, and
> a dashboard syncs to only one AITC service.

True, app receipts themselves aren't tied to the identity. The AITC service is tied to a persona account at the moment though (you push installs and deletes for apps to the AITC service for a specific persona account), so I still see a possibility for conflicts in reference to the AITC service such as what's seen in the bugs attached to this bug (note: I'm more concerned about what happens in bug 761823, given that if you are logged out of an account, you should not be modifications to the AITC service for that account as a result, which right now, happens).

Comment 12

[Jason Smith [:jsmith]]

k9o triage question - Is a kilimanjaro requirement to support multiple personas for apps in the cloud?

Comment 13

[Bill Walker [:bwalker] [@wfwalker]]

Anant, please clarify with thunder and benadida

Comment 14

[Jason Smith [:jsmith]]

I think the importance of this bug is dependent on the UX requirements for the AITC dashboard. I do note that my comment in https://bugzilla.mozilla.org/show_bug.cgi?id=748977#c10 makes me think that this bug is important for k9o, given that a user should be able to understand where their app data is coming from (e.g. is app 1 from persona 1? persona 2?). Otherwise, we could end up in a not so good UX situation where users make modifications without understanding the implications to a certain persona vs. another persona.

Comment 15

[Dan Mills [:thunder]]

(In reply to Jason Smith [:jsmith] from comment #14)
> I think the importance of this bug is dependent on the UX requirements for
> the AITC dashboard. I do note that my comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=748977#c10 makes me think that
> this bug is important for k9o, given that a user should be able to
> understand where their app data is coming from (e.g. is app 1 from persona
> 1? persona 2?). Otherwise, we could end up in a not so good UX situation
> where users make modifications without understanding the implications to a
> certain persona vs. another persona.

I don't understand what the not so good situation is. Why does it matter?

Let me put it another way: iOS allows users to sign in as a different user into the app store and download apps, they get mixed with already-existing apps on the device. I'm sure not everyone is happy with how it works, but it certainly doesn't seem to be any sizable group. Why is our case so different? It feels to me like we're focusing on a total edge case.

Comment 16

[Jason Smith [:jsmith]]

(In reply to Dan Mills [:thunder] from comment #15)
> (In reply to Jason Smith [:jsmith] from comment #14)
> > I think the importance of this bug is dependent on the UX requirements for
> > the AITC dashboard. I do note that my comment in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=748977#c10 makes me think that
> > this bug is important for k9o, given that a user should be able to
> > understand where their app data is coming from (e.g. is app 1 from persona
> > 1? persona 2?). Otherwise, we could end up in a not so good UX situation
> > where users make modifications without understanding the implications to a
> > certain persona vs. another persona.
> 
> I don't understand what the not so good situation is. Why does it matter?
> 
> Let me put it another way: iOS allows users to sign in as a different user
> into the app store and download apps, they get mixed with already-existing
> apps on the device. I'm sure not everyone is happy with how it works, but it
> certainly doesn't seem to be any sizable group. Why is our case so
> different? It feels to me like we're focusing on a total edge case.

Disclaimer: AITC deals with apps that are acquired, not apps that are that are installed (See https://bugzilla.mozilla.org/show_bug.cgi?id=749033#c8 or in general, the whole discussion on that bug).

So to put the iOS case into perspective in our world - when I sign into the iOS store and I view "My Apps," this is where AITC kicks in. What apps do I see at this point? Apps tied to my persona? Apps overall? Downloading apps has to be "user specified" to pull the apps down to a device off the cloud.

Just checked the Google Play store - they appear to distinguish between apps on a per device basis. Additionally, going to My Apps shows apps I've installed for that google account (unless I'm reading it incorrectly).

Comment 17

[Anant Narayanan [:anant]]

I agree with thunder's and rags' conclusions. The way apps currently work is no different than any other user data (bookmarks, history, etc.) in Firefox, so leaving it as-is works for me.

I do not think it is important at this point to distinguish between apps from multiple personas in the dasbhoard. The correct solution is to defer until "sign in to the browser" is implemented, where the user expectations are much more clearer.

We should leave this bug open, however, as when "sign in to the browser" does get implemented we may have to implement persona switching in the DOMApplicationRegistry depending on how SITB is implemented.

By this reasoning, this bug is not a k9o blocker, and by extension, neither are bug 761821 and bug 761823.

Comment 18

[Jason Smith [:jsmith]]

(In reply to Anant Narayanan [:anant] from comment #17)
> I agree with thunder's and rags' conclusions. The way apps currently work is
> no different than any other user data (bookmarks, history, etc.) in Firefox,
> so leaving it as-is works for me.
> 
> I do not think it is important at this point to distinguish between apps
> from multiple personas in the dasbhoard. The correct solution is to defer
> until "sign in to the browser" is implemented, where the user expectations
> are much more clearer.
> 
> We should leave this bug open, however, as when "sign in to the browser"
> does get implemented we may have to implement persona switching in the
> DOMApplicationRegistry depending on how SITB is implemented.
> 
> By this reasoning, this bug is not a k9o blocker, and by extension, neither
> are bug 761821 and bug 761823.

Same disclaimer as in https://bugzilla.mozilla.org/show_bug.cgi?id=761823#c9 - just because SITB is not being implemented means that we completely forget about what we should do to have a good UX in the short-term. The 1st release of AITC I understand and agree why the UX is almost completely undiscoverable (e.g. make sure we can actually test it and make sure the thing works), but I wouldn't agree when we want wide usage of this feature, which I thought was in scope for k9o.

On the same basis that we used with the fennec native bugs, I'll leave this as productwanted and figure it out when we design the "discoverable" version of AITC. If it turns out we find out we actually do need this, then let's revisit that then.

As a general note that was derived from analyzing this:

Talked this over with James, and the conclusion that was reached seems to imply that there could many use cases out here with so many combinations possible that we might want to map this out before reaching the conclusion that this or isn't needed for k9o (e.g. phones, tablets, desktop machines, emails, personas). There's weird scenarios we may not be thinking about initially, such as:

- What happens if I want a different persona for my phone vs. mac machine vs. windows machine?
- What about shared public computers?

I'll leave this unnomed until we can get clarity (thus why productwanted is flagged).

And I end this point with - my brain hurts thinking about this.

Comment 19

[Jason Smith [:jsmith]]

Removing the qa+ mainly cause the bug isn't verified. There's enough rationale actually from other bugs to imply product input isn't needed here any more, so removing the keyword.

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.