Skip to content
This repository has been archived by the owner on Apr 3, 2019. It is now read-only.

WIP feat(sync): choose what to sync on the web #2757

Closed
wants to merge 1 commit into from

Conversation

vladikoff
Copy link
Contributor

Ref mozilla/fxa#18

depends on https://github.com/mozilla/fxa-content-experiments/pull/22/files

To test this you need a build of Firefox with patch applied: https://bugzilla.mozilla.org/show_bug.cgi?id=1183917
and adjust your signup url to force this:

('identity.fxaccounts.remote.signup.uri', fxaEnv.content + 'signup?service=sync&context=fx_desktop_v1&choose_what_to_sync_flow=web&force_choose_what_to_sync_view=web');

};

return able.choose('chooseWhatToSyncMode', abData) === 'web' && flow === 'web';
},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zaach @shane-tomlinson need feedback on the part above ^

'use strict';

// old versions of Firefox do not support the CAPABILITIES message
// we timeout if that is the case
var CAPABILITIES_RENDER_TIMEOUT = 1500;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, how did you pick this timeout value?

@rfk
Copy link
Contributor

rfk commented Jul 31, 2015

Thinking more broadly than just choose-what-to-sync, could this be a generic "initialize" event to which the browser responds as part of the page setup process? It could include its set of capabilities, its info about who is currently logged in (per #2662), and maybe other stuff in the future.

I feel there's a bit of history with how we manage commands flowing back and forth between the page and the host, and I'm not the best person to advise on architecture details here. @shane-tomlinson will likely have valuable input, and I think we should run this past @zaach as it may play into his work on moving android to the web flow as well as #2662.

@vladikoff do you have other potential capabilities in mind at this stage? (#2861 (comment) certainly qualifies, but maybe more?)

@@ -101,6 +102,19 @@ define([
},

/**
* Check if the relier is Sync for Firefox Desktop
*/
isChooseWhatToSyncWeb: function (uniqueUserId, locationParams, able) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be moved to the fx-desktop relier since it's pretty specific to that relier?


self.request(self._commands.CAPABILITIES)
.then(function (response) {
if (response && response.data && _.isObject(response.data)) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there always going to be a response.data? The request call usually resolves the promise with the data field. If there is a data field within that, then there is data.data and that seems strange and we definitely have to make sure all browsers send that format.

@rfk
Copy link
Contributor

rfk commented Aug 2, 2015

The more I look at this PR, the more I think the broker should make this decision.
if(this.broker.supportsChooseSyncCapability('web_v1')) {

Riffing on this a little, and to @vladikoff's broader point about the complexity of implementing lots of custom brokers - can we use this kind of messaging mechanism to delegate all the broker customization points to the host? We have lots of custmization points like canCancel, beforeSignIn, etc. How many of these could be usefullly dispatched as webchannel/postMessage/whatever messages to the hosting code, letting it make dynamic decisions about behaviour rather than encoding all the rules up-front?

@shane-tomlinson
Copy link

Riffing on this a little, and to @vladikoff's broader point about the complexity of implementing lots of custom brokers - can we use this kind of messaging mechanism to delegate all the broker customization points to the host? We have lots of custmization points like canCancel, beforeSignIn, etc. How many of these could be usefullly dispatched as webchannel/postMessage/whatever messages to the hosting code, letting it make dynamic decisions about behaviour rather than encoding all the rules up-front?

This is nearly identical to an idea discussed about a year ago, I think I referred to it as something like "querying the environment". The current terminology of "capabilities detection" is much clearer. I hope we can use this mechanism for all future browser integrations so we can stop creating custom brokers. We'll likely have to keep custom auth brokers around for existing browser integrations, because the browser won't respond to a capabilities message, so we'll still have to specify the behavior for those environments.

As part of capabilities work, I think it would be nice if the browser specified its own halt behavior, I always felt like it was a hack we hard coded that into the content server. If the browser wants us to stop, it should tell us to stop. Maybe this will require us to send messages other than login to the browser, or use the same scheme we use for the auth-server where we send a reason with the session data. The browser could respond to the login message with a halt: true, handing control of stopping the content server back to the browser.

Another place I could see this used - the browser could tell the content server - "no need to poll for signup verification, we have this."

Overall, I'm an emphatic 👍 on the capabilities idea. I want us to get the API "mostly" right, making as few assumptions as possible, which is what I was trying to convey with my review comments. I think I came across as not liking the idea. Sorry @vladikoff, that was definitely not the intention.

@shane-tomlinson shane-tomlinson modified the milestones: avatars-fx41, train 43, train 44 Aug 4, 2015
@ckarlof ckarlof removed this from the train 44 milestone Aug 12, 2015
@vladikoff
Copy link
Contributor Author

Seems like the approach in this PR is not gonna work. Will open a new PR

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants