While debugging another WordPress-related issue, I noticed that once a provider under "more login options" is set as the 'preferred provider', using the form no longer works, producing the following error:
No OpenID Identifier was provided
…which is indeed the case:
Oh noes! The reasons for this are two-fold:
The way the form is supposed to work is that it re-fills out the previously selected values from localStorage, but the code only fully excutes if this.prefs.provider is truthy, which is never the case because the property it should be checking for is this.prefs.name (or name should be renamed provider, since it gets its value from the data-provider attribute to begin with in the signin function).
That problem aside, inserting the username manually doesn't work either because when the provider is auto-selected, openid.provider_url isn't populated, so the #openid_identifier doesn't get filled in. This is an issue even when the problem above is fixed, because swapping in a new username won't result in the appropriate OpenID url being generated in the submitx handler. I refuse to create a Yahoo! account to test what happens for minor providers that don't require a username, but I'll assume it's also not good.
A side-effect of the first bug is that it breaks the stored value for prefs.openid on any subsequent attempt at logging in, due to the following in submitx which sets the value to "" in this scenario:
if (openid.setPref("username", e), openid.setPref("openid", $("#openid_identifier").val()), "" == e)
return !0;
Obviously the user can manually enter their OpenID url or toggle providers to fix this, but we can use the fact that there's going to be minor post-fix inconvenience to pass extra blame to whoever was responsible. 'Tis the season for giving, after all.
