The watch API works great. I like the way auto-login is completely
transparent to the API. Overall, this is easier to implement than the
old api, even though it requires passing the email address into the
client all the time.
However, the new-user email roundtrip doesn't seem to work the way I
was hoping. Is this just still TBD?
I found two behaviors when I log in with a fresh browserid account:
1) If I do the "smart user thing" (ie leave the browserid popup alone,
and click on an email link that pops up in the same browser) then I
get the same old instruction to "go back and find the window with the
website in it". The displayed domain is teasingly unclickable. This
is same as behavior with navigator.id.get().
2) If I do the "dumb user thing" (close the browserid popup, or open
the email link in a different browser) then the UX is *really*
confusing. I don't even get the "go back and find the window"
instruction; rather it seems to just log me into
browserid.org as if
that's what I wanted all along. This is going to terrify a
significant portion of my userbase. I am worried. This might be the
same behavior as navigator.id.get()... I will try it right now.
What I really want to happen:
The final browserid signup screen has a link to my website and a HUGE
button that says "click here to continue". Ideally I can control this
link, but right now I'd settle for it just sending the user back to
the page they were on. When the user gets back to my site, the
watch-onlogin method will be called with their identity.
Is this just pending or did I misunderstand how this is supposed to
work? If it's pending, any idea when this will be in production?
Thanks,
Jeff