730015 - BrowserID: No longer able to Sign In using FF 12 (Aurora) or FF 13 (Nightly)

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[James Bonacci [:jbonacci]]

(pasting in from original BrowserID GitHub issue #1176)

from jbonacci:
I did some further testing based on the issues that @jrgm was having with FF11 on older mobile devices.
So I tried to do just some basic Sign Ins (not even Sign Ups or account creation) using FF 12 and FF13 on Android devices:
1. Android phone running with 2.2 firmware
2. Android table running with 3.2 firmware

Aurora: FF12.0a2 (2012-02-22)
Nightly: FF13.0a1 (2012-02-22)

In both cases, I can load beta.myfavoritebeer.org and click the Sign In button.
After some very interesting screen flashing and other UI/screen artifacts, I do get the diresworb.org/sign_in page.
I can type in login and password.
But the moment I either:
a. select an email to use for sign-in
or
b. click a link (This is not me or Use another email)
I appear to be taken back to the beer site with a "grayed out" Sign In button.
Looking at the URI field, though, it appears I am still actively in diresworb.org/sign_in
If I refresh the page, I am back to the beer site.
I can click on Sign In
I can still see that I have a list of emails to choose from.
But, that is as far as I can get.

Alternatively, I can go to diresworb.org and verify that I am signed in and have a list of emails shown in the Account Manager.
I can sign out from here.
Once I do that, I can start over again at the beer site (not that I will get very far...)


from jrgm:
I tried using the aurora build from 2012-02-16, but it doesn't seem much better. Aurora is getting quite confused about its tab state: from adb logcat lots of these errors when things go wrong.

E GeckoConsole: [JavaScript Error: "BrowserApp.selectedBrowser is null" {file: "chrome://browser/content/browser.js" line: 2193}]
E GeckoConsole: [JavaScript Error: "BrowserApp.selectedBrowser is null" {file: "chrome://browser/content/browser.js" line: 2308}]
E GeckoConsole: [JavaScript Error: "aTab is null" {file: "chrome://browser/content/browser.js" line: 590}]
E GeckoConsole: [JavaScript Error: "this.selectedTab is null" {file: "chrome://browser/content/browser.js" line: 885}]

Comment 1

[James Bonacci [:jbonacci]]

Something changed recently that prevents us from completing the Sign In/Sign Up process of BrowserID on Android devices 2.x and 3.x using FF 12 and FF 13.

The functionality used to be there at least when Aurora was 11 and Nightly was 12.
Now that we are on native, we lost this ability.

STRs
1. Grab an older Android device (3.2 or older), phone or tablet
2. Open beta.myfavoritebeer.org
3. Click Sign In
4. After some delay and some screen flashing/debris, you should get a new tab with an email/password field
This is the diresworb.org/sign_in dialog
5. Enter an email and password (preferably already associated with BrowserID Stage environment to avoid the email verification step).
Alternatively, use a desktop FF to create an account through beta.myfavoritebeer.org
6. Click Select Email
7. You should get the email selection dialog, which for an account of one email, will list only that one email
8. Click on one of the two links or select Sign In

Expected:
You are signed into BrowserID and returned to the beta.myfavoritebeer.org tab

Actual:
The Sign In process does not complete and there appears to be some confusion of tabs in the FF browser - for example we are returned to beta.myfavoritebeer.org but are not actually signed in and the tab appears to be diresworb.org/sign_in not the beer site.

Comment 2

[Matt Brubeck (:mbrubeck)]

I think this is caused by bug 725502.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Did something change in the way BrowserID opens the window? This worked previously.

Comment 5

[Matt Brubeck (:mbrubeck)]

(In reply to Mark Finkle (:mfinkle) from comment #3)
> Did something change in the way BrowserID opens the window? This worked
> previously.

I'm not sure about what BrowserID has done in the past, but it currently uses window.open with "dialog=1" which is known to break native Fennec (bug 725502).

Comment 6

[Shane Tomlinson [:stomlinson]]

:mbrubeck, :mfinkle - thanks for the feedback.

For Fennec, we call window.open with undefined for the window arguments.  We depend on UA sniffing to determine whether the browser is Fennec, but I see that the UA string has changed on Fennec.

Our current check for Fennec is:

var isFennec = navigator.userAgent.indexOf('Fennec/') != -1;

This handles the XUL versions of Fennec, but not the Java versions.

Firefox Mobile 13.0a1 is reporting as it's UA string as:

Mozilla/5.0 (Android: Mobile; rv:13.0) Gecko/13.0 Firefox/13.0a1

Based on https://wiki.mozilla.org/Fennec/User_Agent and https://developer.mozilla.org/en/Gecko_user_agent_string_reference, I am not sure what the best string to sniff for is.  In the former article, the claim is "B2G isn't Android and may well not say "Android"; we will have to work hard to get sites to not sniff for Android going forward. But right now, the Fennec team judged that we need it in there." 

This leads me to ask what the most "future proof" query we can do and be reasonably assured we are looking at Fennec of some sort?  Should we sniff for a combination of "Firefox" and "Android"? Should we sniff for the combination of "Firefox" and ["Mobile"|"Tablet"|"Desktop"]? 

Will normal Desktop Firefox ever get the "Desktop" portion of the string or will this be reserved for netbooks and docked tablets?

Thanks.

Comment 7

[Matt Brubeck (:mbrubeck)]

Because bug 725502 affects only the Android front-end, the best way to work around that specific bug is probably to look for "Android" and "rv:" (or "Android" and "Firefox/").

If you have other reasons to sniff for Fennec, then it depends on exactly what those reasons are....

Comment 8

[Shane Tomlinson [:stomlinson]]

:mbrubeck: Thanks for the quick response, I will do that.

Comment 9

[Shane Tomlinson [:stomlinson]]

Pull request issued: https://github.com/mozilla/browserid/pull/1193

Comment 10

[James Bonacci [:jbonacci]]

Looks like the fix will come in FF 13: https://bugzilla.mozilla.org/show_bug.cgi?id=725502#c13

Comment 11

[JP Rosevear [:jpr]]

We should have this fix in the nightly and on Aurora now.  James, can you confirm its working now?

Comment 12

[James Bonacci [:jbonacci]]

We will need to pull a workaround out of BID code - see Comment 9 above:
https://bugzilla.mozilla.org/show_bug.cgi?id=730015#c9

I will work with Shane on this.

Comment 13

[Aaron Train [:aaronmt]]

Is this resolved? What's the status here? Looking to remove qa-wanted keyword.

Comment 14

[James Bonacci [:jbonacci]]

Aaron see Comment 12.
Shane Tomlinson put in a hack workaround. To really test this fix, we would have to wait until that is backed out.
Let me check in with the BID team on this.

Comment 15

[Shane Tomlinson [:stomlinson]]

:jbonacci, :aaronmt, :jpr - I can confirm that we can remove the hack for Aurora and Nightly, but the UA string of the current Beta as reported by navigator.userAgent is Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/12.0 Firefox/12.0 /12.0 This string does not have "Fennec" in it, which is what we search for with the old hack for XUL Fennec.

Because of a failing Beta and because removing the hack does not cause any user visible change in Nightly and Aurora, this hack should not yet be removed. I am hesitant to remove the hack even after the current Aurora becomes Stable because people that remain on the current Beta (when it becomes Stable) will be borked if we remove it.

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

Shane - Is this bug what we want to use to track "removing the hack"? I'm guessing not and we can close this bug as WFM. Things seem to be working without the hack, where possible, and with the hack, where needed.

Reopen if we need this bug for other reasons.