android back button with ons.notification.alert()

[Michael Redwine]

I am observing a bit of a problem. For testing purposes, I have two pages. A button on page one pushes page two, and this is fine. When deployed to my Android, the back button works as expected: if on page 1, the app exits. If on page two, it goes back to page one. However…

On page two, on “focusout” of an ons-input, I have jquery perform an ajax call to my web server to receive test data (which works). {Yeah, I know… I’ll dump jQ, but it was easy to test ajax to make sure it works in the first place!}. Anyway, when the ons-input loses focus, ajax occurs, which gets a reply, and ons.notification.alert() is called. If I hit the Android’s back button while this notification is up, the app exists. I would expect that the notification would close, then if I hit the back button again, I would go to page one, then if I hit the back button again, the app would exit.

I tested this a little further, and on page one, I have another button, and in this button I have:

 onclick="ons.notification.alert('hello');"

While this message is up, if I hit the android back button, the app closes. This is unexpected behavior… I expect that the alert would close, not that the app would exit.

[Michael Redwine]

@Michael-Redwine As an update, I discovered that this problem doesn’t manifest itself if I set cancelable:true. If I do that, the back button closes the dialog. If I don’t set that, it closes the app.

Expected behavior: device back button does nothing until user dismisses the alert by pressing “OK” (or whatever the button says).

[Fran Diox]

@Michael-Redwine Yep, that’s by default. If the dialog can’t be canceled it calls the parent handler, which is normally the app handler (exit).

Expected behavior: device back button does nothing until user dismisses the alert by pressing “OK” (or whatever the button says).

I think we have different expected behaviors. I wouldn’t want my Android button to be useless even if there is a dialog on the screen. I guess adding cancelable attribute/option is easy enough to deal with this situation :+1:

More info about device back button: https://onsen.io/v2/guide/cordova.html#device-back-button

[Michael Redwine]

@Fran-Diox I agree, but not entirely. I feel there is a legitimate reason to have a notification window prevent the device back button from working. FOr example, my app might alert the user, “Hey stupid, pay up or your account is deleted tomorrow!”. I’m sure you’re like me and probably everybody else on the planet, you’ve hit the back button on a notification in “real” apps out of instinct without ever reading them. Very much like clicking “Accept” without reading the EULA for a program. But some notifications should be purposfully interacted with, such as my example. The user should not be able to click outside the notification box to close it, and should not be able to click the device back button to close it… instead, the user should b required to click “OKAY” or whatever the notification button is.

But, even if we disagree with expected behavior, I think there is one thing that seems natural: if I have a non-cancelable notification visible, hitting the device back button causing the app to close doesn’t make sense. If the notification is cancelable=false, and you hit the device back button, the app closes… that seems the exact opposite of cancelable, but on a larger scale… instead of “not canceling” the notification, it cancels the app.

[Fran Diox]

@Michael-Redwine Could be, but I don’t think it’s the most common use case. You can easily change the global handler and ignore device back button if that’s what you want (explained in the previous link). Or ignore it if document.querySelector('ons-alert-dialog') returns something (i.e. there is an alert in the dom). Or simply disable handlers when you show the alert (ons.disableDeviceBackButtonHandler()). I think any of these possibilities would be enough for that use case.