Cancelling the Touch ID dialog crashes 1p

io41

im using iOS 8.1.3 on an iPhone 5s.

Stephen_C

What version of 1P are you using (see 1P Settings and look towards the bottom of the screen for the version number)?

Stephen

io41

I'm using version 5.2.

Jasper

Hi @io41,

This is by design, actually. If you cancel the Touch ID entry, the app will close.

If you would like to switch to master password entry, please use the "Enter Password" option instead.

Please let us know if you have any questions.

io41

Really? So any work I was doing will be lost if I cancel the dialog after task switching? Why?

io41

Isn't the safer option (in order to not loose any work in progress, such as open pages and in the 1P browser) to simply leave 1P locked, just like what happens when you task switch away from it to another application?

hawkmoth

I'm reasonably sure that developers who use Touch ID have no control over the Touch ID process. IReally, I would think the option currenly labeled Cancel should be labeled Quit instead. But only Aplle could make that change.

I don't know what control a developer might have over what happens when the current Cancel code is retured to the underlying application.

io41

Surely the Touch ID process is initiated from within a running application and not bound to whether or not an application launches? I suspect the Touch ID process is bound to a trigger (probably the reading of the password from the keychain), and thus it should not force an exit of the application, but rather just dismiss the dialog and remain locked. That way no user state is lost. (Aside: I don't think forced exists are recommended practice.)

io41

With regards to exiting the application:

In iOS, the user presses the Home button to close applications. Should your application have conditions in which it cannot provide its intended function, the recommended approach is to display an alert for the user that indicates the nature of the problem and possible actions the user could take — turning on WiFi, enabling Location Services, etc. Allow the user to terminate the application at their own discretion.

Warning: Do not call the exit function. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen.

( from https://developer.apple.com/library/ios/qa/qa1561/_index.html )

hawkmoth

Thanks for the clarification.

ag_kevin

Hi @io41,

Are you seeing lost changes? Unsaved changes should be preserved, they just don't "take effect" until they are explicitly saved. I did a little test and here's what I found:

1. Edited a secure note and put "test" at the top of the note.
2. Switched to another app
3. Switched back to 1Password and tapped Cancel. The app quit.
4. Opened 1Password again, and navigated to the note I was editing. Instead of "Edit" in the top right corner, it says "Resume Editing." If I tap that, I can see the changes I was making.

If you are seeing lost work, please let us know the steps to reproduce it.

This issue has been debated by our staff extensively. The reason 1Password quits is because there is nothing to display to the user and there's nothing the app can do if you tap Cancel. If the app did nothing it will appear to have frozen. It could display the Master Password field, but that's what the Master Password button does. It might be confusing if Cancel does the same thing. And iOS does not let us remove the button from the dialog box.

I hope that explains why it quits, and it certainly shouldn't be losing any changes you've made in the app. Please reply if you have further questions or comments.

io41

Hi @hayesk,

I initially reported the problem in this forum from the 1Password browser and had filled out the title and description but did not "post" it yet. I wanted to confirm that it does indeed crash, so I pressed the home button, and then opened up 1Password again, using my fingerprint and I was back in the 1Password browser, with my filled out, yet unposted form again. No data lost, the entire web page's state was maintained. Now I pressed the home button again, and then opened up 1Password, this time cancelling the Touch ID dialog. There's the typical flicker of an app crashing (it just disappears, without any animation or warning). When I opened up 1Password again and authenticated via the Touch ID dialog, the 1Password browser was no longer open and it's state lost. I had to fill out the forum post again.

I can see how it might be confusing to display the Master Password field, but I'd argue that a user is cancelling the dialog, not the launch of the 1Password application (that is, they don't want to unlock 1Password). Once that dialog shows, if it was an intentional or accidental switch to 1Password, there's nothing that can be done: A user is forced to either authenticate or cancel; while the Touch ID dialog shows, the home button is disabled. I should think that if a user cancels a dialog, then the dialog closes but does not quit the entire application. There may not be anything useful I can do in 1Password if I've cancelled the authentication dialog, but I think showing the Master Password field is better than a hard exit and loosing state. Perhaps in that case it make sense to show a message along the lines of "Your 1Password is locked, protecting your data from unauthorised access." Maybe it's possible to display an "Unlock with Touch ID" button if the user accidentally cancelled, along with the Master Password field?

I often search for my PIN entries for my credit cards before going to pay. The last opened entry stays open, so when it's time to enter the pin, I only need to unlock and there it is. Unless I've accidentally switched to 1Password before then and didn't want to unclock, the cancel exists and 1Password forgets what entry I had open. This one is no big deal, but it's frustrating non-the-less.

Further more, it's not just an open webpage's state that's lost, but the entire browser's state. All open tabs. By forcing an exit, 1Password is deciding for the user that the application is to terminate, rather than leaving this choice to the user.

Kindest Regards,
Tim

littlebobbytables

Hi @io41,

As you've noted, it's a difficult one no matter what we do.

1. We can't gracefully send the application to the background, the ability doesn't exist.
2. We shouldn't quit the application.
3. We can't alter the Touch ID screen - we've passed total control to Apple at that point.
4. If we were to display the Master Password field the danger would be if people mistake seeing it to mean the Master Password will now be required, as if they'd selected the Enter Password option.

The last one is important. I know for a fact that we have users that when they've selected that option expect 1Password to remain locked until the Master Password is supplied. If we created a situation where we led them to believe it was securely locked and it wasn't... You can imagine the backlash.

So that leaves a limbo type page or the current (which we shouldn't). At the moment it would seem the best workaround for a user in your situation is to see the unlock though and then send 1Password to the background. Not ideal but it would bypass the loss of state. We'll take what you've said on board of course.

io41

Hi @littlebobbytables,

Thanks, that's a very good point and I see the dilemma you're in. One approach might be:

but I know I'm no UI/UX designer :)

Best of luck finding a solution, I know these things are very hard.

Best Regards,
Tim

Ben

Thanks for sharing your thoughts, Tim. :)