How do you propagate an error resulting from auth.getRedirectResult so that you can display it in UI?

[Richard Walker]

I'm using the following Firebase authentication boilerplate. But the redirect that results is not allowing me to display a message about the normal expected error when it occurs.

firebase.auth().getRedirectResult().then(function(result) { // NOTICE REDIRECT
  if (result.credential) {
    // This gives you a GitHub Access Token. You can use it to access the GitHub API.
    var token = result.credential.accessToken;
    // ...
  }
  // The signed-in user info.
  var user = result.user;
}).catch(function(error) { // NOTICE CATCH
  // Handle Errors here.
  var errorCode = error.code;
  var errorMessage = error.message;
  // The email of the user's account used.
  var email = error.email;
  // The firebase.auth.AuthCredential type that was used.
  var credential = error.credential;
  // ...
});

The catch(function(error)) behaves as expected: it's used to catch an "email already associated to another provider" error, for instance.

My problem/question is this: I need to display the error message in the UI to the user. But when I do it gets wiped out on the redirect (to the same UI view). I don't know how to stop the redirect, or otherwise retain and display the error message to the user.

Here's my code for displaying the error message (my modification to the catch in the boilerplate):

}).catch(function(error) {
  // Handle Errors here.
  var errorCode = error.code;
  var errorMessage = error.message;

  // Handling account-exists-with-different-credential
  if (errorCode == 'auth/account-exists-with-different-credential') {
    emailAddrMsg.textContent = errorMsg; // getElementById not shown
    emailAddrMsg.removeAttribute('hidden'); // NOTICE REMOVE HIDDEN
    return false;
  }
});

The emailAddrMsg element is hidden by default when the page is loaded, and that's exactly what happens on the redirect after an error—it is hidden, so the error message does not get displayed to the user. In fact, the error goes out of scope all together because the redirect re-instantiates all state. Thats one problem stemming from following Firebase documentation!

<p><input id="emailaddr" type="text" name="emailaddr" placeholder="email address" class="input-text"></p>
<p hidden id="emailaddr-msg" class="error-msg"></p>

This error display mechanism (hiding and showing) works fine when I do client-side error checking, but the involvement of the redirect api call to firebase messes with the ability to display the error message. Firebase does not provide any examples of display templates for errors.

Thanks for your help.

[Michael Tangen]

I'm running into the same thing but when using firebase.auth().signInWithEmailAndPassword() within toggleSignin()

Any error messages that I output to the DOM appear for a split second but then are stripped from the DOM.  I don't get it.

The example documentation uses an alert() for notifying the user of messages, but let's face it — that's an antiquated way of notifying the user of issues.  It'd be nice if the auth documentation would provide an example for handling inline messages.

[Kato Richardson]

Hi folks,

Are you, by any chance, trying to capture the output on the source page instead of the destination? Keep in mind that getRedirectResult() is intended to use on the destination page and not the source page you redirect from.

☼, Kato 

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0bddd737-d39c-44f5-ad02-718e9dbcb716%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Richard Walker]

Ah, good, let's work together on this Michael. Thanks for your reply. What you describe about the quick flash of the message before it disappears is also my experience. This happens because we are creating the display of the error message which occurs just before the Firebase api call completes. When it does repeat, if there is a redirect that causes the page to refresh, as in my case, the dom view is altered and the previous state involving the error message is wiped away (goes out of scope).

I'm thinking I need to explore a couple different lines of investigation. First, per the main introductory Firebase tutorial, my JavaScript module state is tied to the page view. In other words the HTTP/URL that loads the page calls the JavaScript which instantiates the UserAuth object for processing FB.auth calls. If any auth call causes a page redirect (even back to the same page) then the JavaScript module gets re-instantiated and previous state is lost, resulting in the loss of the view with the error message.

So one idea would be to somehow stop the redirect (which I don't know how to do at this point), and another might be to propagate the error in the response which is causes the redirect so that its state is available on that successive page view.

Does this make sense? Hopefully someone with further experience might have some ideas to contribute.

[Richard Walker]

Yes, Kato, thanks. But can you give a hint as to how to do this per the api? I know how to intercept the error state in the catch block, which is where I was then able to make calls to display the error message in the view, but when the enclosing auth.getRedirectResult  function returns it causes the redirect and then I don't see how/where that state is propagated to the subsequent view, which is the same page in my case.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0bddd737-d39c-44f5-ad02-718e9dbcb716%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Tangen]

So I spent a few hours banging my head last night on this with no result — but then this morning something inside me said "remove the <form> tag" — I did that and the page stopped reloading and the error messages remained when testing auth().

So for whatever reason, if your login fields are within a <form> tag — even if there's no attributes in the form tag itself — any button click event does run any events  you have associated with it, but also triggers this to run again:

window.onload = function() {
 console.log('window load');
 initApp();
};

...even if the window itself isn't reloading.

So I'm not sure if you've got <form> tags in yours, but try it without if you do.  

On a related note, it kinda bugs me that the example authentication page shows a form but is not using good form syntax — there's no containing <form> tag and there are no corresponding label tags for each of the inputs.  I think Google needs to clean that up a bit.

[Michael Tangen]

Oh and one more point that I came across when messing around with this whole <form> tag thing — if you do have it present, throw an event on there to trigger your login function and then the window.onload() won't refresh.

<form onsubmit="signIn(); return false;">