Closed Bug 1069920 Opened 6 years ago Closed 6 years ago
Firefox Accounts auth dialog does not wait for password
Env: Flame, build version: flame-KK.user.v2.0.B-4.Gecko-92ec39f.Gaia-31434a3 Loop client version: c8eb6e8 STR: 1. Sign in Fx Account from settings -> Firefox Account 2. Install Loop client (for the first time) 3. Open Lopp, and after passing the wizard, choose "Use Firefox Accounts" 4. Instead of writing the password, close the screen from "x" in top left corner. ACTUAL RESULT: Signed-in in loop with FxAccount. EXPECTED RESULT: Return to previous screen or warning telling that the password is required.
[Blocking Requested - why for this release]: This is a regression. Allowing direct access without checking the password is pretty bad.
blocking-b2g: --- → 2.0?
Hardware: x86 → ARM
Summary: First time one application is installed (LOOP) and previously FxAccount registered in general settings, when password is asked, you can login without writing the password. → Firefox Accounts auth dialog does not wait for password
The problem here is that both .watch and .request make use of FxAccountsManager.getAssertion, so while one of these calls waits for the UI result, the other one continues with the regular process of getting the assertion.
Attachment #8493175 - Flags: review?(spenrose)
Comment on attachment 8493175 [details] [diff] [review] v1 The attribute is this._refreshing, not this.refreshing. r=me with typo fixed. Thanks very much for fixing this (bad) bug. I only saw it a minute ago, but the fact that it could exist makes me unhappy. It suggests we don't have a clear enough understanding of the state machine, or enough unit test coverage.
Attachment #8493175 - Flags: review?(spenrose) → review+
Thanks Sam! https://hg.mozilla.org/integration/b2g-inbound/rev/20353b5d9530 (In reply to Sam Penrose from comment #5) > > Thanks very much for fixing this (bad) bug. I only saw it a minute ago, but > the fact that it could exist makes me unhappy. It suggests we don't have a > clear enough understanding of the state machine, or enough unit test > coverage. I added a few tests along with the patch.
Whiteboard: [platform][blocking] → [platform][blocking][patch available]
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S5 (26sep)
BLocking given this is a regression, can you please seek b2g32/aurora approval to land this on 2.0 and 2.1?
blocking-b2g: 2.0? → 2.0+
Comment on attachment 8493175 [details] [diff] [review] v1 Approval Request Comment [Feature/regressing bug #]: FxA authentication [User impact if declined]: This is a regression. Allowing direct access without checking the password is pretty bad. [Describe test coverage new/current, TBPL]: Added unit tests along with the already existing ones. [Risks and why]: Low risk [String/UUID change made/needed]: None
Comment on attachment 8493175 [details] [diff] [review] v1 Adding verifyme for QA verification once this lands on 2.0
Verified it on FxOS v2.0. It returns to welcome page. (Start using Firefox Hello...) * Build information: - Gaia 279c5ee3a2b4cfd1484196a409e05ef579de1b53 - Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f5655da30c8b - BuildID 20141002160200 - Version 32.0 - ro.build.version.incremental=27 - ro.build.date=Thu Sep 4 14:59:02 CST 2014
Verified on: Dev: Flame / Gecko-8f91e4c.Gaia-31a49c7 Loop client version: 83b17d9 RAM: 512Mb
Status: RESOLVED → VERIFIED
Verified on: Dev: Flame / Gecko-8f91e4c.Gaia-31a49c7 Loop client version: 83b17d9 RAM=512M
This issue has been verified successfully on Flame 2.0, 2.1, 2.2 and woodduck 2.0. The Loop version:bd8f1c2 See attachment: 1351.MP4 Reproducing rate: 0/5 Step: 1. Sign in Fx Account from settings -> Firefox Account. 2. Install Loop client (for the first time). 3. Open Lopp, and after passing the wizard, choose "Use Firefox Accounts". 4. Instead of writing the password, close the screen from "x" in top left corner. ACTUAL RESULT: Device will return to previous screen(Start using Firefox Hello...). Woodduck version: Gaia-Rev ead3b72a84512750bc5faff4e9e8faa1715c0d05 Gecko-Rev 8d40d6480ee0e628b0f7655dcd6ff79a2f2fbcfc Build-ID 20141211050313 Version 32.0 Device-Name jrdhz72_w_ff FW-Release 4.4.2 FW-Incremental 1418245573 FW-Date Thu Dec 11 05:06:41 CST 2014 Flame 2.1 version: Gaia-Rev c226db212db4d824c09617cd6dc407b2d4258d9b Gecko-Rev https://hg.mozilla.org/releases/mozilla-2g34_v2_1/rev/cf8bebfa4703 Build-ID 20141210001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141210.035300 FW-Date Wed Dec 10 03:53:11 EST 2014 Bootloader L1TC00011880 Flame 2.2 version: Gaia-Rev e17c5656dbf517d48fb61ac9bc92119e023fd717 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/be1f49e80d2d Build-ID 20141210040201 Version 37.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141210.074809 FW-Date Wed Dec 10 07:48:20 EST 2014 Bootloader L1TC00011880 Flame 2.0 version: Gaia-Rev 856863962362030174bae4e03d59c3ebbc182473 Gecko-Rev https://hg.mozilla.org/releases/mozilla-2g32_v2_0/rev/2d0860bd0225 Build-ID 20141210000202 Version 32.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141210.034839 FW-Date Wed Dec 10 03:48:50 EST 2014 Bootloader L1TC00011880
You need to log in before you can comment on or make changes to this bug.