See screenshot. You can't close that view. You can't tap behind it. There's no OK button, only a 'Cancel' button.

Grabbing this bug while I'm waiting for some interaction on https://bugzilla.mozilla.org/show_bug.cgi?id=1341456

[:aaronmt], I can't seem to ever get a 'Cancel' button. I am only ever seeing a '< Settings' button.

Using an iPad?

Well, an iPad Simulator, yes ;) . I can use an actual iPad if you have observed the behavior there.

:eoger, :stomlinson, what do you think of this one?

:st3fan - I have seen this behavior as well and thought it was a bit funky. In another lifetime far far ago, for Desktop and Android, we used to display a blue "Sync Settings" button on the final screen. When users clicked on the button, the browser's Sync settings panel would then display. We removed the button because it was causing users to do bad things to their browser settings and be confused. Perhaps we could do something similar here, but instead of showing a "Sync Settings" button, we'd show a "Close" button. If the user clicks "Close", we'd message Fx for iOS, and you'd close the panel. Or, we could send a message to Fx for iOS as soon as that last screen is displayed. Fx for iOS could then change the "Cancel" button in the top left to a "Close" button, or provide some alternative action for the user.

Disregard iPad only. Taken off of 7.0 on the store.

How can we get that bug moving? I encountered it during testing (I think it's during first run only) and it seemed pretty bad (only possible action: home menu).

(In reply to Edouard Oger [:eoger] from comment #8) > How can we get that bug moving? I encountered it during testing (I think > it's during first run only) and it seemed pretty bad (only possible action: > home menu). I agree, it's not ideal. I'd like to get :rfeeley's input, but ISTM there are at least two possible approaches. 1. Add some UI to FxA's `/signup_confirmed` and `/signin_confirmed` screens that allows the user to close the panel. If the user clicks a button, we notify the browser of the user's intent. Pros - it's obvious to the user what to do. Cons - the UI is not part of the browser, but rather FxA. We'd have to ensure to only show the UI if the browser supports it. 2. When `/signup_confirmed` or `/signin_confirmed` are displayed, we send the browser some notification, perhaps `verified` or similar. When the browser receives the notification, it changes the `cancel` button to `close`, or simply removes the panel. Pros - no new FxA UI. All UI handled by the browser. Cons - A browser button might not be as obvious as an FxA button. This is pretty easy for both signin and signup. Password reset might be a bit more tricky. I haven't tried password reset from this pane to see how it currently acts. :rfeely & :sleroux - thoughts?

Both options sound reasonable to me. For option (2), the handling of a new message on our end from the WebView to update the state of the button should be trivial if we want to give that way a try first since it seems like the cheapest option from the FxA side of things. I guess the only confusing this would be the scenario where the user is required to verify their email before they can be confirmed. Since the only way to go back is to hit 'Cancel' it might seem that the user is cancelling the whole sign in process. Would it be possible to show the close button while we're waiting to be verified maybe?

tl;dr but can't we just label it "Done". i talked with st3fan about this yesterday and he thought yet. Also it's available in iOS.

Still seeing this on beta 8.0

Please use "Done". Chrome uses "Done" (or their × close icon). Cancel is not an appropriate label.

Just read Ryan's note on this, to change this to Done with no required communication from the server. I was just in bug triage where we misunderstood this bug to require some server-side indication the button should change.

This has been merged.

Uplifted to v9.x

Verified as fixed on master 9baa97b.