Lock: Callback not called on widget close.

[MicahZoltu]

lock.showSignin(options, (error, profile, idToken) => {
    console.log("called");
}

If I click the x in the top right corner of the popup then "called" is not logged.

I'm using the GitHub release 7.5.4.

[MicahZoltu]

https://github.com/auth0/lock/blob/master/index.js#L1272
https://github.com/auth0/lock/blob/master/index.js#L490
On those lines, hide is called with no parameter.

https://github.com/auth0/lock/blob/master/index.js#L490
On that line we can see that hide expects a callback parameter.

https://github.com/auth0/lock/blob/master/index.js#L505
Without the callback passed into hide, this function will never call the callback so the application won't be notified.

This is problematic for me because I can't tell the difference between the user waiting with the dialog open and the user closing the dialog. If they close the dialog without logging in then I need to give them some kind of feedback letting them know that they will need to authenticate to complete whatever action they attempted. As it is now, if the user doesn't log in then the page just stalls, assuming the lock popup is still open.

[cristiandouce]

The callback parameter is not expected, it's just optional as you well noted below in here: https://github.com/auth0/lock/blob/master/index.js#L505.

Right below that we emit a hidden event which is emitted right after we invoke the optional callback.

If you want to get notified when the Lock is hidden, just do this:

lock.on('hidden', () => {
  console.log("lock hidden!")
})

The show callback is used to invoke on an authentication success/error. Not for the lock show/hide/ready events.

[MicahZoltu]

From an API design standpoint, I believe it would be better if the callback passed to show...() was always called when Auth0 was done.

When I show the pop-up dialog, my application is effectively passing control to Auth0 and blocking while it waits for authentication to complete. I need a reliable mechanism for knowing when Auth0 is done so I can proceed with my business logic (branching on whether the user is logged in or not). Realizing that the 'hidden' event is the mechanism for knowing when I am done is very counterintuitive. I expected to have my callback called by Auth0 when it was done doing "whatever it is that it does" but instead I only get that callback called in some situations.

At the least, this should be clearly documented since it goes against user expectations.

Handling this in my application is also more painful than if the callback were always called.

Code with callback getting called always:

let authPromise = new Promise((resolve, reject) => {
    lock.showSignin(options, (error, profile, idToken) => (!error) ? resolve(profile) : reject(error));
}

Code with callback getting called only on success/failure:

let authPromise = new Promise((resolve, reject) => {
    let profile = null;
    let error = null;
    lock.showSignin(options, (_error, _profile, _idToken) => { profile = _profile; error = _error; });
    lock.on('hidden', () => (profile) ? resolve(profile) : reject(error || "Popup closed."));
}

In the above snippet, I am operating under the assumption that the lock dialog cannot be hidden _before_ showSignin calls the callback. If this is not true then I would be introducing a bug in my code due to the complexity of having to listen for two callbacks for effectively (from my point of view) the same operation.

[cristiandouce]

We don't call the callback when the lock is open. From a consistency point of view we don't call it either when it's close.

The Lock done way of thinking all the Lock's process was never part of the API design.

The callback provided as I already mentioned is for authentication events only. Also internally it prevents an oauth redirect (using a popup/xhr request) avoiding leaving the page por Single Page Applications.

For the lock's lifecycle we designed some events (which we will also complete in few). Documentation for those events are here: https://auth0.com/docs/libraries/lock/events. (they used to be in this repo's wiki but moved all to our docs page)

Since I understand your point of view, I'll reopen this issue for discussion.

I stand with the idea that returning an Error for a lock lifecycle is not an approach I'm inclined to implement. It's a Promise thing which I'd be glad to implement in some other way.

[cristiandouce]

By the way:

let authPromise = new Promise((resolve, reject) => {
    lock.once('hidden', () => reject("Popup closed."));
    lock.showSignin(options, (error, profile, idToken) => {
        lock.off('hidden');
        (!error) ? resolve(profile) : reject(error);
    });
}

Callback is always called before:
https://github.com/auth0/lock/blob/master/index.js#L1200

If it's not then it's a bug on our side.

[swarajban]

@cristiandouce Would be great if your last solution was documented. I agree with the decision to keep show's callback exclusively for authentication events, but I think you should communicate that the callback isn't called when the lock is hidden. When reading the docs, there is no indication that people even need the events documentation to deal with this.

[swarajban]

Also @cristiandouce, looks like there is no lock.off. There is only removeAllListeners and removeListener

[dsullivan7]

If anyone's curious about this functionality for >= v10, the syntax is:

lock.on('hide', () => {
  console.log('the modal has been hidden')
})

[huan]

The above code from @cristiandouce looks good but it's outdated now(v10.14)

let authPromise = new Promise((resolve, reject) => {
    lock.once('hidden', () => reject("Popup closed."));
    lock.showSignin(options, (error, profile, idToken) => {
        lock.off('hidden');
        (!error) ? resolve(profile) : reject(error);
    });
}

Has there anyone implemented a new version of Promise Encapsulated code with v10.14? I want to use Auth0Lock in my Ionic2/Angular app.

Thanks!