-
-
Save thomcc/dbd5b79195ae02580e1aebf7fc4cc19e to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
from #sync | |
<kitcambridge> i got the impression yesterday that CC might be at risk for 56 because the master password encryption story still needs some work | |
<tcsc> Thom Chiovoloni yeah that's my impression too, but this patch has a CC sync engine | |
<tcsc> i mean, should we delete it? | |
<kitcambridge> ^ MattN, did i misunderstand, and we need to test credit card sync for 56, too? | |
<tcsc> Thom Chiovoloni the current engine is basically trivial sicne it shares so much code with the addr engine | |
<kitcambridge> i think it's OK if we still land the engine, but don't register or expose it | |
<tcsc> Thom Chiovoloni hmmm | |
<MattN> kitcambridge: probably safer to not land it yet unless it's going to be a maintenance burden to maintain out of the tree. | |
<kitcambridge> MattN: ok, we can hold off and get the diff from MozReview when it comes time to land CC | |
from #formfill | |
<~MattN> tcsc: You do need to do a check since we may do a gradual rollout since we're a system add-on i.e. not everyone on 56 will necessarily have it. We are definitely going to rollout based on locale + geoip | |
<~MattN> tcsc: Can we expose an API for you instead of a pref? | |
<~MattN> Since I'm not yet sure how we will do the rollout | |
<tcsc> i changed things so that this will land in the same folder as your stuff e.g. it's part of the engine | |
<tcsc> although definitely i'd prefer calling some functions to reading some prefs, it's up to you | |
<~MattN> tcsc: which of our modules is your code already importing? That way I know where to put an API | |
<tcsc> just profile storage it looks like | |
<~MattN> hmm… ok… we may want to put in on FormAutofillUtils.jsm then since storage isn't an ideal place | |
<tcsc> heh, i figured | |
<tcsc> but, as i mentioned, this is also going to land as one of your modules (i think we'll request review on it... somewhat soon?), so maybe it's not worth doing that | |
<tcsc> totally your call though | |
<~MattN> tcsc: yeah, I understand but just because our modules are shipped in the browser it doesn't mean we want them available/enabled | |
<~MattN> since for example, the geoip lookup would happen after download | |
<tcsc> got it. | |
<~MattN> If you want to unblock landing feel free to add two APIs (one for each data type) in the Utils JSM or else check the prefs for now | |
<tcsc> sure | |
<tcsc> MattN: would a single function that took a string (like the same collectionName profileStorage uses) bother you? it would avoid us needing to add a function that gets overridden in subclasses | |
<~MattN> sure, that's fine |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment