If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

How should Firefox Accounts behave in a container tab?

NEW
Unassigned
(NeedInfo from)

Status

()

Core
FxAccounts
P3
normal
7 months ago
2 months ago

People

(Reporter: rfkelly, Unassigned, NeedInfo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 months ago
This is a follow-up from discussion in Bug #1323853, which asked the same question about private browsing mode.

The current behaviour can be observed in two ways.  First:

1. Sign in to Sync in your browser
2. Navigate to https://addons.mozilla.org and click on "log in"
3. Observe that you can login without re-entering your password, because FxA knows you're already signed in in the browser
4. Open a new container tab
5. Navigate to https://addons.mozilla.org in this container tab and click on "log in"
6. Observe that you're prompted to sign in again, because the container tab "doesn't know" that you're signed in to the browser itself.

In this case, the current behaviour seems like it's plausibly the Right Thing, but it's largely an accident of some implementation details rather than a deliberate choice.  Is it the right thing, and should we e.g. add some tests to ensure we don't regress this behaviour?


Second, try this:

1. Sign in to Sync in your browser
2. Open Preferences -> Sync, 
3. Observe that you're taken to the FxA settings page on the web, and you're logged in because  you're in a logged-in browser.
4. Open Preferences -> Sync again, right-click on "Manage Account", and select "open in new container tab".
5. Observe that you're prompted to sign in, because the container tab "doesn't know" that you're signed in to the browser itself.


This is a bit weirder.  It shouldn't be possible for the user to click on that link in such as way that it fails to work.  Should we try to somehow prevent opening this link in a container tab?

:baku, Ehsan suggested you as a good person to ask about this, could you please weigh in or redirect as appropriate?
Flags: needinfo?(amarchesini)

Comment 1

7 months ago
I thought I'd already commented on this bug. I'm fairly sure I'm just going to rehash my opinions from the "private browsing" bug...

(In reply to Ryan Kelly [:rfkelly] from comment #0)
> 6. Observe that you're prompted to sign in again, because the container tab
> "doesn't know" that you're signed in to the browser itself.
> 
> In this case, the current behaviour seems like it's plausibly the Right
> Thing,

IMO, that's the wrong thing. The user *is* signed in to the browser and making it look like it isn't is wrong IMO. For example, a user may decline to log in and make decisions based on the fact they are not logged in when they actually are.

> 1. Sign in to Sync in your browser
> 2. Open Preferences -> Sync, 
> 3. Observe that you're taken to the FxA settings page on the web, and you're
> logged in because  you're in a logged-in browser.
> 4. Open Preferences -> Sync again, right-click on "Manage Account", and
> select "open in new container tab".
> 5. Observe that you're prompted to sign in, because the container tab
> "doesn't know" that you're signed in to the browser itself.
> 
> 
> This is a bit weirder.

Agreed - anything that might seem weird to the user should be considered broken. The fact is that the FxA mechanisms and UI were all designed to seem as though you were logged in to the browser; trying to have some UI pretend you aren't while other key parts of the UI insist you are is a recipe for confusing our users.
You need to log in before you can comment on or make changes to this bug.