1256470 - Enable Passcode/Touch ID for Private Browsing Mode

Status: REOPENED

(Firefox for iOS :: General, defect, P3)

Description

[Robin Andersen [:tecgirl]]

Attachment: TouchID&Passcode-On-TouchOn.png

Requirements:

    Passcode/Touch ID is used for accessing Provate Browsing mode (optional)

User Stories:

    As a user, I want to have a secure and convenient way to browse in private mode.
    As a user, I want to have the option to enable Passcode/TouchID for PBM

Acceptance Criteria:

    Passcode/TouchID option is offered for access to PBM

Comment 1

[Nathanael Alcock]

The interface mockup presented might not be the most accessible way to provide those options to the user. At the moment, it will look like you are toggling just Touch ID for Private Browsing / Logins, whereas it is more likely the user would want to turn off security entirely for those features (it would be strange for the user to want security for both, but only touch ID for one).

Would this set of settings be more user-friendly?

Turn Passcode Off
Change Passcode

Require Passcode (Immediately)
Enable Touch ID       [x]

Use Touch ID & Passcode for:
Private Browsing      [x]
Logins                [x]

Comment 2

[Robin Andersen [:tecgirl]]

Makes sense; though now we'll need to set them both to default to on, since one or the other would be weird and none would likely annoy users who didn't notice the toggles, set a passcode, and nothing happened.

Comment 3

[Robin Andersen [:tecgirl]]

Attachment: TouchID&Passcode-On-TouchOn Updated.png

Comment 4

[Nathanael Alcock]

Attachment: Pull request

Comment 5

[Stephan Leroux [:sleroux]]

Comment on attachment 8766041 [details] [review]
Pull request

Left comments on the PR. I think we need to rethink how we present and authenticate the user from the current model of using the TabTrayController.

Comment 6

[Nathanael Alcock]

Would it make sense to replace the term "Touch ID & Passcode" with something less technology-specific such as "Authentication" in the setting title and the subtitles for the specific features to enable authentication for?
This way, we also don't have to have additional logic for having different label text depending on whether the user has Touch ID enabled.

Comment 7

[Robin Andersen [:tecgirl]]

From what I can tell, specifically labeling the feature seems to be the convention — though I can't find anything specifically calling it out in the docs. We should have a different label to let the user know what kind of auth they will be entering. I don't think the red thumbprint in the dialog is enough.

Comment 8

[Nathanael Alcock]

Comment on attachment 8766041 [details] [review]
Pull request

There's been a fair amount of refactoring since the earlier pull request, and I think all of the changes have been implemented. Would it be possible to take another look at it?

Comment 9

[Stephan Leroux [:sleroux]]

master 7e95b152aa21e60da4357133eec22cdb5c1dc1ba

Comment 11

[Nathanael Alcock]

Rolled back in: https://github.com/mozilla/firefox-ios/commit/324fd75aefeb4be2c11b0fe3727c49fac6bcc123

There were issues with these changes, especially with top tabs, so this is being reöpened until those are fixed.

Comment 12

[Nathanael Alcock]

Attachment: Pull request

Here's my second go at implementing this feature. Deferred has been replaced with callbacks, and a significant number of bugs involved with the top tabs work have been fixed. Also added a couple more tests, which cover problems we had before.
Sorry, I know this one is going to be a pain to review! However, it's still fundamentally based off the original patch, so that might make things a little simpler.

Comment 13

[Stephan Leroux [:sleroux]]

Moving to 7.0 to stabilize the 6.0 release.

Comment 14

[Aaron Train [:aaronmt]]

Pending PR need review for 7.0?