I’ve been having trouble with my back button disappearing sometimes when transitioning to child states and I’ve been working on tracking down what’s causing it. I have found a number of people with the same issue, but it seems most have the issue randomly. I have recognized a specific set of circumstances that cause this and I’m hoping to find a way to fix the issue. Here’s what is happening:
Everything works fine on normal start-up of the app. When freshly installed, the app opens directly to the Auth0 login widget. Once I login, everything works as expected. Great. If I am logged into the app and log out, then back in, everything works as expected again. If, however, I open the app after not using it for a while and it it calls the Auth0 login widget after partially loading the app (without populating with data), then this problem arises. The app loads the default tab, again without data, then recognizes I need to login and opens the login widget. Once I login, if I click on any of the links/buttons/items that take me to child sates of that default tab, the child state loads, but there is NO animation and the back button does not show up.
At first I thought maybe this was because I was only requiring login (logInRequired = true) for the abstract state (tabs), but I fiddled around with that and it didn’t fix the issue. Something is happening only when the Auth0 widget is called after the app is partially loaded. Has anyone encountered this issue? Any ideas on how to fix it? I’m not encountering any errors and it doesn’t happen in Chromium browser testing.
I’d be happy to include a codepen, but honestly I’m not sure what to include at this point.
Fixing the back-button issue is most important to me, but ideally the animations as well.
Nobody? It seems that there is no recognition that a state change is happening. Could this be because stateChangeStart isn’t running for some reason? I really need to figure this out.
Here is my login controller:
.controller('LoginCtrl', function($scope, auth, $state, store) {
auth.signin({
closable: false,
// This asks for the refresh token
// So that the user never has to log in again
authParams: {
scope: 'openid offline_access'
}
}, function(profile, idToken, accessToken, state, refreshToken) {
store.set('profile', profile);
store.set('token', idToken);
store.set('refreshToken', refreshToken);
auth.getToken({
api: 'firebase'
}).then(function(delegation) {
store.set('firebaseToken', delegation.id_token);
$state.go('tab.posts');
}, function(error) {
console.log("There was an error logging in", error);
})
}, function(error) {
console.log("There was an error logging in", error);
});
})
It seems the behavior is a result of when there is an error connecting to Firebase and I redirect the user to the login state. Should I be doing this differently? As I said, this behavior only happens when the posts state partially loads and an error results in sending the user to the login state. If the user is directed to the login state immediately (such as when the app is first run on the device or after the user logs out) everything works perfectly.
.service('Posts', function($firebase, store, $state) {
var postsRef = new Firebase("Firebase URL");
postsRef.authWithCustomToken(store.get('firebaseToken'), function(error, auth) {
if (error) {
// There was an error logging in, redirect the user to login page
$state.go('login');
}
});
Any thoughts?
So I’ve found that after logging in the nav bar CSS is changed to:
nav-bar disable-user-behavior no-animation
Specifically,
<ion-nav-bar class="nav-title-slide-ios7 bar-dark bar bar-header nav-bar disable-user-behavior no-animation">
<ion-nav-back-button class="button-icon icon ion-arrow-left-c button back-button ng-hide">
</ion-nav-back-button>
Does anyone have any ideas what is triggering this? I assume this is happening because there is initially an error logging in, but I need to be able to revert the nav bar back to using animations and the back button once the user is logged in properly. What triggers this? Can I turn off this change to no animations and no user behavior? The user can’t access the app until they are logged in anyway, so I would like to avoid this functionality completely.