Facebook initial login, 'Create Account' dialog leaves Email field blank


(Andreas Grimm) #1

there’s this behavior where when one of our team members is trying to initially login (register) via facebook, the email field stays blank … and disabled. Thus she can not login via Facebook because the ‘Create Account’ button is disabled as well.

This is on OS X in Safari with locale ‘en’:

… it’s the same on OS X in Chrome with locale ‘de’:

(she has now logged in via Google account, to get stuff going)

At this very same workstation, for a different facebook user account the email text box get’s preset without a problem.

[edit] it’s with version 0.9.8.10


(Jeff Atwood) #2

I believe under some circumstances Facebook will not send the email address.

Not sure exactly why that happens, perhaps some specific settings / permissions in that individual account?

edit: could be intermittent bugs in the FB platform? Facebook not always returning email for user? · Issue #61 · mkdynamic/omniauth-facebook · GitHub

https://developers.facebook.com/bugs/298946933534016

Some possible reasons:
No Email address on account
No confirmed email address on account
No verified email address on account
User entered a security checkpoint which required them to reconfirm their email address and they have not yet done so
Users's email address is unreachable

You also need the 'email' extended permission, even for users who have a valid, confirmed, reachable email address on file.

(Andreas Grimm) #3

so as a result of this, it seems we simply can’t be totally sure that facebook returns the user’s email.

what would be a better user experience compared to simply not being able to login (clicking in disabled fields and on disabled buttons) and not knowing why this doesn’t work (no info/warning/error message gets displayed)?

enabling the email field in the case of facebook not returning an email? … maybe with the hint to use same email address as on facebook?
oh no, when facebook doesn’t provide an email address then facebook login won’t work at all, right?

what about at least adding some guidance for the user ?


(Jeff Atwood) #4

We need some data on how often this happens on the FB side.

The previous link implies 2% of FB users have unvalidated emails or some other problem where their email is not valid, yet they have a FB account:

I experience the same problem, currently in cca 2% of user registrations. I also don’t use the JS dialog login, only the oauth flow.


(Andreas Grimm) #5

ok, then I’ll try to convince my team to go live nevertheless.

I have to get into how page customization works and add some info to the login page and an email address where users can get help if experiencing such problems. hopefully this will be ok for our team.
being a ruby and docker beginner, I first have to find out how to customize things in the live running docker instance and not running into trouble when updating to newer versions.

in general of course this then isn’t a problem specific to discourse and there’s nothing one can do to solve the problem from a technical point of view.

thank you for providing the 2 links and the information on this.


(Jeff Atwood) #6

We need to understand the number of users that have email problems on FB – if you can provide early data on how many users you are seeing this with, and whether they meet the following criteria:

  • No Email address on Facebook account
  • No confirmed email address on Facebook account
  • No verified email address on Facebook account
  • User entered a Facebook security checkpoint which required them to reconfirm their email address and they have not yet done so
  • Users’s Facebook account email address is unreachable

… then we can look at next steps.


(Andreas Grimm) #7

Is there a way to automatically log these special events? If not, how would I otherwise find out?


(Jeff Atwood) #8

@neil can we add some sort of log event when we get account creation attempts from Facebook users where the email is not present?


(Neil Lalonde) #9

Ok, will log it in the user_histories table.


(Ramon Gonzalez) #10

I was unable to create an account via the Facebook login as well. I tried it with three different accounts, and only one of them got the email field populated. For the other two, the email field did not get populated, nor could it be edited. Same behavior @andreas noticed.

All three account have the same privacy settings. Pretty standard, nothing extreme. However, Discourse could only access the email for one of them. All of them have confirmed emails. Thus, definitely, under certain circumstances some emails are unreachable.

Account with reachable email:

Accounts with unreachable email:

Anyhow, after I removed the primary email and added it back again (for one of the accounts with unreachable email), I was able to create an account just fine.

The only difference between these accounts is that the two that didn’t work originally were created on 2005. The one that did work was created merely two years ago. Perhaps after a long time old emails (Unintentionally?) fall again on the unvalidated/unconfirmed bucket?

I hope this helps.


(phil) #11

I wanted to share my experience with Facebook login with discourse 1.2.0.beta1

  • Sign up using the Facebook login option
  • Redirected to the Facebook page, IF you decide to uncheck the box to not share your email address.
  • Redirected to discourse, the email field is ‘grayed out’ and you can’t finish the registration.
    – I open the browser inspector and removed the css rule that was blocking input of the email address, and after that I entered my email address and was able to validate the signup form on discourse.

(Jeff Atwood) #12

This is not a supported login flow. We need email.


(phil) #13

Yeah I understand but only problem is that you assume the email will come from Facebook, ignoring the fact that Facebook allows the user to uncheck the email sharing option.

And once the user is on the discourse last step of the registration, he/she can no longer enter the email address as the field is ‘locked’. Discourse will show a warning message saying the email is required, but still doesn’t allow the user to access the email field.

A fix would be to test:

  • IF Facebook does NOT transmit the email, then discourse final registration step should leave the email field open to input.
  • IF Facebook does transmit the email, then discourse final registration step can lock the email field.

(Andreas Grimm) #14

imho regardless of supported flows, the user shouldn't ever be able to get in a state where he feels stuck or actually got stuck. that'd be a bad UX, not really usable.

maybe if FB doesn’t provide user’s email, then just implicitly switch to local registration in which flow the user is officially allowed to enter his email manually.and yes, of course he then has to validate that email adress.

it just shouldn’t ever happen that the user gets presented an empty, disabled email field.


(phil) #15

+1 to that… simple and effective.

May be add a little message, after testing that Facebook did not provide the email: "Facebook did not share your email address so we are redirecting you to the regular registration. If you still want to use Facebook login, please click here to change your Facebook preference and allow us to see your email address so that we can send you a confirmation email’.


(Andreas Grimm) #16

sounds great. this way the user knows what’s going on (in which flow he is) and is still able to correct things and switch back to facebook flow.


(Greg Kempe) #17

In our experience in South Africa, one of the reasons Facebook doesn’t provide the email address is because the user registered on Facebook using their cellphone number, not an email (this is common on older phones).

+1 for phil’s suggestion – if Facebook doesn’t give us enough auth info, then let the user complete the missing components or fall back to regular auth.

Here’s pull request: Facebook auth without an email should allow user to enter email by longhotsummer · Pull Request #3030 · discourse/discourse · GitHub


(Sam Saffron) #18

I just merged in your fix, seems totally reasonable to me.


(Khoa Nguyen) #19

It seems like this problem solved :


(Jeff Atwood) #20