Closed Bug 694383 Opened 13 years ago Closed 13 years ago

QA and deploy BrowserID train-2011.10.13 to production

Categories

(Infrastructure & Operations Graveyard :: WebOps: Labs, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lloyd, Assigned: jbonacci)

References

Details

ChangeLog including issues resolved: 
https://github.com/mozilla/browserid/blob/c9b7bd/ChangeLog#L1-17

[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.
No longer depends on: 676702, 678951, 680290, 688572, 690474
QA Contact: zandr → jbonacci
Assignee: server-ops-labs → jbonacci
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: https://github.com/mozilla/browserid/issues/214
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: browserid.org/include.js should have link to unminified source
441: Bug 694541 - E-mail messages from browserid.org have bad DKIM signatures (according to Yandex.ru)
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 https://diresworb.org/
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 diresworb.org "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: https://diresworb.org is confusing for a signed in user
439: The behavior when confirming an email while signing up from diresworb.org should be consistent with the one when doing it from the client
OK. QA was able to Verify all resolved/closed issues from 10/06/2011 and 10/13/2011 trains!
Yea!
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?

Verification:
Using a Samsung Galaxy running 2.2 Firmware plus Stock Browser.
From beta.myfavoritebeer.org, I get the following appropriate message:
"Unfortunately, your browser does not meet the minimum HTML5 suport required for BrowserID." then an OK button.
From diresworb.org, 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 diresworb.org side but not be able to access the client.
I am wondering if we need some helpful message on the diresworb.org 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.  https://github.com/mozilla/browserid/issues/325
Since we have moved to using JSON objects for all responses, I need to check whether I can re-enable older Android devices.
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...
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.
QA signs off on the 10/13/2011 train in Beta.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Blocks: 696415
Blocks: 697785
No longer blocks: 697785
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.