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

Logins aren't available in private browsing mode

NEW
Unassigned

Status

()

Firefox for iOS
Browser
2 years ago
2 months ago

People

(Reporter: rnewman, Unassigned)

Tracking

(Blocks: 2 bugs)

unspecified
All
iOS
Dependency tree / graph

Firefox Tracking Flags

(fxios+)

Details

(Whiteboard: [PasswordManager][PrivateBrowsing])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Maybe a mis-step in Bug 1204539?

Saved logins should be available in private tabs, even if we don't offer to save new ones.

Firstly, this is desktop parity.

Secondly, this is useful and expected -- private browsing isn't just used for porn, it's also used for account switching (i.e., starting with an empty cookie jar) or simply to avoid recording history. The hypothetical user shopping for a wedding ring needs to get their PayPal login to complete their task!


STR:

* Log in with a Google account (or whatever) and save the password, or sync a login such that it'll autocomplete in a normal tab.
* Open accounts.google.com in a private tab.


Actual:

* Nothing. No access to saved passwords.


Expected:

* Text field is auto-populated with your email address, OR
* Autocompletions are offered if you type the start of your email address. (This is what desktop does.)
(In reply to Richard Newman [:rnewman] from comment #0)
> Firstly, this is desktop parity.

Not exactly since the bug summary says "auto-fill" and we don't auto-fill in private windows, only autocomplete. It seems like you may be using autocomplete and auto-fill interchangeably though we consider them separate things in the password manager. AFAIK, FxiOS hasn't implemented any login selection UI regardless of whether in a private context or not.

> * Log in with a Google account (or whatever) and save the password, or sync
> a login such that it'll autocomplete in a normal tab.

Nit: I believe we only offer auto-fill, not autocomplete currently.

> * Text field is auto-populated with your email address, OR

This will leak your identity to the webpage in a private context so I don't think this is a good idea.

> * Autocompletions are offered if you type the start of your email address.
> (This is what desktop does.)

If we can do this in a way that the webpage doesn't see then that would be great e.g. as a toolbar above the keyboard.

iOS Safari adds a "Autofill password" entry on that toolbar (beside the < > for field navigation (like Shift-Tab + Tab) IIRC and if there are multiple we could probably pop up a widget for the user to choose the desired one.
(Reporter)

Comment 2

2 years ago
(In reply to Matthew N. [:MattN] from comment #1)

> Not exactly since the bug summary says "auto-fill" and we don't auto-fill in
> private windows, only autocomplete. It seems like you may be using
> autocomplete and auto-fill interchangeably though we consider them separate
> things in the password manager.

Yeah, my terminology is imprecise. Thanks for the clarification; I've tweaked the summary to better express what I mean.
Summary: Logins don't auto-fill in private browsing mode → Logins aren't available in private browsing mode
Flags: needinfo?(rnewman)
(Reporter)

Comment 3

2 years ago
Presumably the needinfo is "how important do you feel this is?".

I'd aim for 1.3! PB mode is pretty hamstrung without it, and this shouldn't be super difficult to do, but I think much of our 1.2 work will be on pure reliability.
Flags: needinfo?(rnewman)
Sorry - should have clarified. We were discussing what the difference between auto-fill/auto-complete is and determining what the correct way of resolving this is. I agree with having it in 1.2 if it's reliable/low risk.
(Reporter)

Comment 5

2 years ago
ni to Maria to file a card and link this up to 2.0 passwords stuff.
tracking-fxios: ? → 2.0+
Flags: needinfo?(mpopova)

Comment 6

2 years ago
Created Aha card and linked to this bug:
 FIOS-219 - Make Logins available in private browsing mode
Flags: needinfo?(mpopova)
(Reporter)

Updated

2 years ago
Rank: 2
tracking-fxios: 2.0+ → +
Assignee: nobody → jhugman

Comment 7

2 years ago
The following requirement (from security team) should be included as part of this bug fix:

* No password filling on HTTP sites
Status: NEW → ASSIGNED
Fixing this bug as:

 * offer logins in private browsing using the same mechanism as non-private browsing.
 * do not offer logins in either private browsing or non-private browsing for http pages
 * do not offer to save new logins or changed logins in private browsing.

Current auto-fill/auto-complete:
 * on load and on blur events of the username field, the password is filled. This against the advice in Comment #1
Created attachment 8716941 [details] [review]
Pull request
Attachment #8716941 - Flags: review?(sarentz)
Attachment #8716941 - Flags: review?(rnewman)
Blocks: 1246182
(Reporter)

Comment 10

2 years ago
(In reply to James Hugman [:jhugman] [@jhugman] from comment #8)

> * do not offer logins in either private browsing or non-private browsing
> for http pages

We don't want to do this until we have autocomplete and manual fill. Can we shift this logic into a separate PR for Bug 1246182? (And file bugs for those things?)
Attachment #8716941 - Flags: review?(sarentz)
Attachment #8716941 - Flags: review?(rnewman)
Assignee: jhugman → nobody
Status: ASSIGNED → NEW

Updated

2 months ago
Whiteboard: [PasswordManager]

Updated

2 months ago
Whiteboard: [PasswordManager] → [PasswordManager][PrivateBrowsing]
You need to log in before you can comment on or make changes to this bug.