feat(client): Sync state with the browser! #4695
Conversation
1460fd5
to
71614ac
| /** | ||
| * A variant of the FxSync broker that speaks "v4" of the protocol. | ||
| * | ||
| * It used to enable syncPreferencesNotification on the verification complete screen. |
shane-tomlinson
Mar 2, 2017
Author
Member
This comment lies.
This comment lies.
8dab6bf
to
7dd3bec
|
This is no longer WIP and ready to go. This goes along with the Firefox patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1308038 |
7dd3bec
to
62da580
|
@rfk, @vladikoff - no rush on this, mind starting an r when you have time? Testing requires m-c w/ the browser patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1308038. |
|
This looks good to me, but I want to dig into the interaction between localStorage and private-browsing mode just in case there are any edge-cases to worry about here. |
| account.set(_.pick(userData, 'email', 'sessionToken', 'uid', 'verified')); | ||
| account.set('sessionTokenContext', SESSION_TOKEN_USED_FOR_SYNC); | ||
|
|
||
| return user.setSignedInAccount(account); |
rfk
Mar 6, 2017
Member
This persists the data from the handshake into localStorage, right? I wonder whether that will cause trouble for us when using this in private browsing mode, if the data so written then becomes available to other tabs in the same private-browsing window. I'll try to build m-c with this patch and find out, but it will take a while as I don't have my dev environment set up on this machine yet...
This persists the data from the handshake into localStorage, right? I wonder whether that will cause trouble for us when using this in private browsing mode, if the data so written then becomes available to other tabs in the same private-browsing window. I'll try to build m-c with this patch and find out, but it will take a while as I don't have my dev environment set up on this machine yet...
shane-tomlinson
Mar 6, 2017
Author
Member
You are correct, we write to this tab's localStorage so the data will be available even in PB mode to subsequent browses to an OAuth relier in this same tab. If we avoid writing to localStorage, we'll break users of non-PB mode who subsequently visit an OAuth relier.
You are correct, we write to this tab's localStorage so the data will be available even in PB mode to subsequent browses to an OAuth relier in this same tab. If we avoid writing to localStorage, we'll break users of non-PB mode who subsequently visit an OAuth relier.
| return user.setSignedInAccount(account); | ||
| } else { | ||
| const signedInAccount = user.getSignedInAccount(); | ||
| user.removeAccount(signedInAccount); |
rfk
Mar 6, 2017
Member
Is there anything in the account that we should destroy at this point, e.g. oauth tokens?
Is there anything in the account that we should destroy at this point, e.g. oauth tokens?
shane-tomlinson
Mar 6, 2017
Author
Member
That question can be applied more broadly about how we should be handling signed out accounts. I have a feeling that's a can of worms that'll explode this PR and could be handled independently.
That question can be applied more broadly about how we should be handling signed out accounts. I have a feeling that's a can of worms that'll explode this PR and could be handled independently.
| }); | ||
|
|
||
| describe('capabilities', () => { | ||
| it('has the `allowUidChange` capability', () => { |
rfk
Mar 6, 2017
Member
This test title is the only occurrence of "allowUidChange" in the PR, is it a hangover from a previous naming convention?
This test title is the only occurrence of "allowUidChange" in the PR, is it a hangover from a previous naming convention?
shane-tomlinson
Mar 6, 2017
Author
Member
copy/paste error
copy/paste error
Actually, it's not clear precisely how this is enforcing the 'only request "fxa_status" IFF service=sync' requirement from https://bugzilla.mozilla.org/show_bug.cgi?id=1308038#c27; it looks like it will request status from the browser whenever context=fx_desktop_v4, but does that guarantee that service=sync? |
3825534
to
bee596a
bee596a
to
5c1641e
5c1641e
to
b89af11
b89af11
to
b6b54c9
|
@mozilla/fxa-devs - r? I'm calling this ready. This patch works for real using today's Nightly. Use fxa-dev-launcher to point to a local install, and give it a whirl! Things to test:
Another thing to note - I've started a |
| * Defaults to `this.getUserAgentString()` | ||
| * @returns {Boolean} | ||
| */ | ||
| isFxaStatusSupported (userAgent = this.getUserAgentString()) { |
philbooth
May 25, 2017
Contributor
TIL that default values can be function calls and have access to this.
TIL that default values can be function calls and have access to this.
|
|
||
| const channel = this._notificationChannel; | ||
| return p().delay(TEST_REQUEST_DELAY_MS) | ||
| // OAuth reliers will have `service` set to the client_id, Sync to `sync` |
philbooth
May 25, 2017
Contributor
Not sure if it's just me but part of this comment reads back to front. Should it be "...will have the client_id set to service"?
Not sure if it's just me but part of this comment reads back to front. Should it be "...will have the client_id set to service"?
philbooth
May 25, 2017
Contributor
No, it shouldn't. Sorry, just woken up here.
No, it shouldn't. Sorry, just woken up here.
shane-tomlinson
May 25, 2017
Author
Member
I was just thinking this comment doesn't really provide any value. I'll just rip it out instead of causing more confusion. The comment on lines 125-127 are the informative ones.
I was just thinking this comment doesn't really provide any value. I'll just rip it out instead of causing more confusion. The comment on lines 125-127 are the informative ones.
| // If trying to sign in to an OAuth relier, prefer any users that are | ||
| // stored in localStorage and only use the browser's state if no | ||
| // user is stored. | ||
| return !! (service === Constants.SYNC_SERVICE || this.getSignedInAccount().isDefault()); |
philbooth
May 25, 2017
•
Contributor
Looks like the explicit !! is unnecessary here? === returns a boolean and so does account.isDefault(). Not a big deal obviously but may be a trifle more readable without it?
Looks like the explicit !! is unnecessary here? === returns a boolean and so does account.isDefault(). Not a big deal obviously but may be a trifle more readable without it?
|
@shane-tomlinson, this is great! LGTM, WFM, r+. |
* Remove a comment that makes no sense. * Remove an extra !!, the value was always going to be Boolean anyways.
Very early stage yet, putting this up so we don't forget about it. Goes along with https://bugzilla.mozilla.org/attachment.cgi?id=8832820
Perform a handshake with the browser to use the browser as the canonical
source of truth when it comes to signed in accounts.
issue #4252
https://bugzilla.mozilla.org/show_bug.cgi?id=1308038