QA and deploy BrowserID train-2011.10.13 to production



Infrastructure & Operations Graveyard
WebOps: Labs
7 years ago
2 years ago


(Reporter: Lloyd Hilaiel, Assigned: jbonacci)





7 years ago
ChangeLog including issues resolved:

[QA] Suggested areas of focus for QA:
  * full regression of closed issues
  * basic pass of testing, significant internal API changes could have introduced browser-specific breakage (issues 217 and 325)
  * authentication is 6x slower, bang on this a bit, does there ever feel like there's too much of a delay when you log in?

[RELEASE ENGINEERING] No ad-hoc steps.  just push.


7 years ago
No longer depends on: 676702, 678951, 680290, 688572, 690474


7 years ago
QA Contact: zandr → jbonacci


7 years ago
Assignee: server-ops-labs → jbonacci

Comment 1

7 years ago
BTW: We've now moved to socketlabs for dev and beta, and prod is configured, but will move when this train rolls.  

This is a configuration change, and the code change which supports it is listed in the changelog:

Comment 2

7 years ago
QA picked this up and started testing during last Friday's BrowserID Test Day #1.

Here are the new bugs from that work and some other opened issues:
423: Sign-in popup has no scrollbars → confusing when zoomed in
424: add the existing "Sign in" link to browserID home page
425: Sign In with iOS5 results in weird tab behaviour
426: Create a medium-technical FAQ page 
427: iPhone4: The "need help?" link on Sign In page does not open SUMO
428: Opening BrowserID from an Android WebView gives HTML5 error
429: Provide better email/domain name handling
430: Prevent malicious verification flooding of e-mail addresses of others
431: Initial repoze.who browser id plugin
432: should have link to unminified source
441: Bug 694541 - E-mail messages from have bad DKIM signatures (according to
442: Bug 694562 - browserID sign in page shows a blank tab on iOS5
443: Bug 694580 - Enforcing better passwords
444: Bug 694586 - Small typo on the verify email address page.
445: Bug 694596 - Trying to submit the email for browser id does not work correctly
446: Bug 694619 - BrowserID - Deleting an account does not delete user's data and saved sessions with websites
447: Bug 694632 - BrowserID - Cannot see multiple accounts from Account Manager at
448: Bug 694679 - Better messaging for issues with connection
449: Bug 694686 - "How It works" link does not work on iOS 5
450: Bug 694691 - "Need Help?" link needs colorization
451: Bug 694692 - Help does not fit in the signin window for iOS 5 apps
452: Bug 694693 - "forgot your password?" should be colorized to indicate it as a link
453: Bug 694708 - Ui for adding a different email address is spaced out on iOS 5
421: Functionality for adding emails should also be added in the Account Manager
435: The "remove" button is not displayed fine in IE9 and Opera
436: The message displayed after confirming an email address should be corrected
437: The message displayed when removing the last email address should be modified
438: is confusing for a signed in user
439: The behavior when confirming an email while signing up from should be consistent with the one when doing it from the client

Comment 3

7 years ago
OK. QA was able to Verify all resolved/closed issues from 10/06/2011 and 10/13/2011 trains!
A very big thanks to Ioana for doing a lot of this work...

Also, on this one item:
Android < 3.0 (browsers that can't handle JSON.parse("null")) now blocked explicitly (until we complete support)
--> What is the issue number?

Using a Samsung Galaxy running 2.2 Firmware plus Stock Browser.
From, I get the following appropriate message:
"Unfortunately, your browser does not meet the minimum HTML5 suport required for BrowserID." then an OK button.
From, I am able to Sign In and Sign Out with a current beta account.
Using Sign Up, I click the link to sign in with a current account, which opens the Email/Password menu.
That works, as does account creation.
I assume this is the functionality/compatibility we expected, but it's a bit confusing to be able to work from the side but not be able to access the client.
I am wondering if we need some helpful message on the side if we can run the same test we do on the RP to determine firmware version/HTML5 compatibility.
The Android < 3.0 issue is #325.
Since we have moved to using JSON objects for all responses, I need to check whether I can re-enable older Android devices.

Comment 5

7 years ago
Shane - I am wondering about the priority of this?
Seeing as most mobile devices are quite disposable and people upgrade/change them out frequently.

How much of our audience is using older Android devices?
Of those, how many are unable to upgrade?

Just wanting to make sure I do not create extra work for you to get this backward compatibility put in...

Comment 6

7 years ago
Never mind previous comment. Looks like Shane jumped in and got this going, see:
461: Check whether android < 3.0 can be used with new JSON responses.
QA will verify good compatibility on older devices in the next release.

Comment 7

7 years ago
QA signs off on the 10/13/2011 train in Beta.
Last Resolved: 7 years ago
Resolution: --- → FIXED


7 years ago
Blocks: 696415


7 years ago
Blocks: 697785


7 years ago
No longer blocks: 697785
Product: → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.