Re: Replacing Sync notification bars

I like it! On Thu, Apr 16, 2015 at 11:19 AM, Ryan Feeley wrote: > Hi deep syncers, > > After a chat with Ryan Kelly the other day I’ve come to realize that Firefox > will be requiring the current password for some time to come (i.e. sync will > disconnect when the FxA password is changed on the

Re: Forced sync upgrade

Still technically possible, but it will not be eventually. We're working on completing the migration "old Sync" users to "new Sync" (bug 1014406), scheduled to occur in the Firefox 37 cycle, and then we will eventually remove the "old Sync" support code in the client. Gavin On Sat, Mar 7, 2015 at

Re: Sync Transition not ready

Cloud Services > Mozilla UX > IRC: rfeeley > > On Feb 5, 2015, at 11:59 AM, Gavin Sharp wrote: > > Right, so that's expected. We won't be flipping these switches for > release users until 37 is on release, and you'll get the better > experience there. > >

Re: Sync Transition not ready

> UX, Cloud Services > Mozilla UX > IRC: rfeeley > > On Feb 5, 2015, at 11:59 AM, Gavin Sharp wrote: > > Right, so that's expected. We won't be flipping these switches for > release users until 37 is on release, and you'll get the better > experience there.

Re: Sync Transition not ready

Right, so that's expected. We won't be flipping these switches for release users until 37 is on release, and you'll get the better experience there. Gavin On Thu, Feb 5, 2015 at 8:46 AM, Ryan Feeley wrote: > Release, latest > > > On Feb 5, 2015, at 11:37 AM, Gavin

Re: Sync Transition not ready

+sync-dev That looks like the UI you get when you're on a version of Firefox prior to 37 (we can't modify those versions, you need to upgrade to 37+ to continue migration). Which version were you testing with? Gavin On Thu, Feb 5, 2015 at 8:34 AM, Ryan Feeley wrote: > Hi Syncers, > > Just trie

Re: Sync Migration and how to pull the trigger.

Sounds good to me! Gavin On Wed, Dec 10, 2014 at 4:01 PM, Mark Hammond wrote: > In today's Sync Engineering meeting we discussed how to "pull the trigger" > for the actual migration, particularly with consideration to Firefox 37 > riding the trains. > > Background: The sync migration code in Des

Re: Back-compat extension #3: search history

Isn't search history a subset of form history? (Bug 461820 prevented it from being saved/retrieved for web forms, but as far as I know the storage is still shared.) Gavin On Thu, Nov 6, 2014 at 2:11 PM, Richard Newman wrote: > (For context, see >

Re: telemetry data on sync and master password

They seem high to me! Gavin On Thu, Sep 25, 2014 at 5:03 PM, Stefan Arentz wrote: > > On Sep 25, 2014, at 2:02 PM, Chris Karlof wrote: > > We put in some telemetry probes to measure master password usage in Nightly. > Below are the results in for Fx34. > > Roughly 2% of general users have a mas

Re: Tracking server-side FxAcct issues for Desktop Sync in 29

Great. Thanks Chris! Gavin > On Feb 13, 2014, at 6:27 PM, Chris Karlof wrote: > > >> On Feb 13, 2014, at 5:56 PM, Gavin Sharp wrote: >> >> It looks to me like the bug tracking situation for issues filed >> against desktop but that are actually related to th

Tracking server-side FxAcct issues for Desktop Sync in 29

It looks to me like the bug tracking situation for issues filed against desktop but that are actually related to the accounts.mozilla.com content/backend is currently not ideal. I've been moving such bugs to Mozilla Services::Server: Firefox Accounts and putting them in the dependency list of http

Sync-related bugzilla components

Here's my understanding of which Sync-related bugs should go where. If anyone wants to disagree or elaborate/clarify, that'd be great. = Firefox Desktop = - Firefox::Sync for UI Bugs, which includes: Sync preferences, Sync menu panel, panel notifications, about:accounts container (but not about:a

Sync in 29 desktop blocking list

https://bugzilla.mozilla.org/showdependencytree.cgi?id=969593&hide_resolved=1 is the list of client-side bug considered "blockers" to shipping Sync in 29. A lot of those bugs are in non-actionable state: not clear how to reproduce, not clear whether they are still issues, etc. Some focused QA he

Re: Desktop 29 bug list clean-up

OK, thanks. Sounds like "not 29" to me. Gavin On Sun, Feb 9, 2014 at 12:46 AM, Ryan Kelly wrote: > On 8/02/2014 9:58 AM, Richard Newman wrote: >>> - https://bugzilla.mozilla.org/show_bug.cgi?id=927527 support for >>> "over-quota" notification >> >> I don't believe we currently track quotas, so t

Re: Desktop 29 bug list clean-up

Tracy pointed out via email that the current component situation is rather confusing. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=969924 to address this. Gavin On Fri, Feb 7, 2014 at 2:18 PM, Gavin Sharp wrote: > One other proposal I'd like to make, while I'm on a roll:

Re: Desktop 29 bug list clean-up

On Fri, Feb 7, 2014 at 2:58 PM, Richard Newman wrote: >> - https://bugzilla.mozilla.org/show_bug.cgi?id=951373 per-client sync >> options (seems like Android made this switch, so we need to as well?) > > We did not do this for Android, though it would (have) made things easier in > both places.

Re: Desktop 29 bug list clean-up

ync UI > > can we batch move bugs? > > > - Original Message - > From: "Gavin Sharp" > To: sync-dev@mozilla.org > Sent: Friday, February 7, 2014 2:18:26 PM > Subject: Re: Desktop 29 bug list clean-up > > One other proposal I'd like to make, while I&

Re: Desktop 29 bug list clean-up

a Service::Sync Backend for issues related to the sync backend (i.e. bugs in code that lives in services/) Gavin On Fri, Feb 7, 2014 at 2:13 PM, Gavin Sharp wrote: > Hello syncers, > > Apologies for the bugspam many of you no doubt received, but I've done > some work cleaning up ou

Re: Desktop 29 bug list clean-up

server back-off - https://bugzilla.mozilla.org/show_bug.cgi?id=927527 support for "over-quota" notification Gavin On Fri, Feb 7, 2014 at 2:13 PM, Gavin Sharp wrote: > Hello syncers, > > Apologies for the bugspam many of you no doubt received, but I've done > some work clea

Desktop 29 bug list clean-up

Hello syncers, Apologies for the bugspam many of you no doubt received, but I've done some work cleaning up our bug lists. We'd previously been using bug 905997 (along with bug 951296, confusingly) as a catch-all for all issues related to desktop accounts-based Sync. The dependency list included

Re: boom headshot!

It was a great week. There's still a lot of work in front of us to actually ship this thing, but a lot of important foundational work was completed this week, and hitting this milestone feels good. I think ckarlof, markh, ttaubert, zaach, jedp, rfeeley and jgruen deserve a special thanks for the t

Latest Desktop test build

These builds, from the (near) tip of fx-team, contain all of the client-side fixes we believe we need to enable Sync by default on Nightly. http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-team-linux64/1391125283/ http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx

Re: Desktop bug tracking for enabling Sync on Nightly

will be on resolving the remaining UI bugs and tackling the other blockers of bug 964922, as well as reviewing landed strings with UX prior to the Aurora uplift. Gavin On Tue, Jan 28, 2014 at 12:49 PM, Gavin Sharp wrote: > The desktop Sync team sat down with ckarlof to do a triage of our > near-t

Desktop bug tracking for enabling Sync on Nightly

The desktop Sync team sat down with ckarlof to do a triage of our near-term priority bugs. We generated two bug lists: a) UI bugs introducing new strings that need to land before the Aurora uplift: https://bugzilla.mozilla.org/showdependencytree.cgi?id=964920&hide_resolved=1 b) bugs needed befor

Re: Desktop Sync try builds

On Fri, Jan 24, 2014 at 10:47 AM, Gavin Sharp wrote: > - I had some issues with the verification and initial sync starting Specifically: The verification email took a while to arrive, and so the build I created an account with gave me: A promise chain failed to handle a rejection. Date:

Desktop Sync try builds

Mark posted his latest patch queue to Try: https://tbpl.mozilla.org/?tree=Try&rev=6491b18e2079 Builds are available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mhamm...@skippinet.com.au-6491b18e2079/ There are a few known issues with these: - the test failure (not sure what th

Re: How to verify email address?

What about "manage account"? Gavin On Thu, Jan 23, 2014 at 12:06 PM, Chris Karlof wrote: > > On Jan 22, 2014, at 1:16 PM, Gavin Sharp wrote: > >> I agree that if we want these items in 29, they need to be handled by >> about:accounts (i.e. the extent of the

Re: How to verify email address?

I agree that if we want these items in 29, they need to be handled by about:accounts (i.e. the extent of the implementation requirements for the client should be "open about:accounts", maybe with a special parameter to indicate context). Who from the FxA team can comment on the feasibility of that

Re: what about:accounts should show after user has logged in

On Wed, Jan 15, 2014 at 10:54 PM, Mark Hammond wrote: > Indeed, the current mockups I've got don't show an "unlink device" (or even > the older concept of "log out") link in the Sync UI at all - the *existing* > sync UI has such an element, but none of the mockups for that UI when an Fxa > account

Re: What do do when a user logs into a different Firefox account?

Chad, Madhava and I met with Mark Hammond and Tim to talk this through yesterday. Our conclusions were: a) We should add explanatory prompts on log-out, and on second-log-in-with-different-ID b) no changes to UI flow otherwise (leave "Sign in to Firefox" menu panel item, which we had discussed rem

Re: What do do when a user logs into a different Firefox account?

On Mon, Jan 13, 2014 at 11:12 AM, Richard Newman wrote: > • Strongly discourage users from signing out of FxA. Bury that option in the > Sync settings, and explain what it does. (Ideally, don't even call it > "signing out"; you're "turning off Sync and signing out of FxA".) AIUI, our only "sign

Re: Walkthru of FxA/Sync Account Creation

on their phone, or if their > desktop mail client opens our verification link in another browser. > > JG > > > - Original Message - > From: "Richard Newman" > To: ga...@gavinsharp.com > Cc: jgr...@mozilla.com, sync-dev@mozilla.org > S

Re: Walkthru of FxA/Sync Account Creation

lready? If so, why? > > (we'll need something along these lines for 2pw anyway.) > > (Phone; please excuse brevity.) > > > -Original Message- > From: Gavin Sharp [ga...@gavinsharp.com] > Received: Wednesday, 08 Jan 2014, 5:40PM > To: Richard Newman [rnew.

Re: Walkthru of FxA/Sync Account Creation

> > We shouldn't start sending (and downloading and irrevocably merging!) the > user's data before they've had a chance to change the defaults for those two > decisions, regardless of how they enter the setup process. > > (Phone; please excuse brevity.) > > > -

Re: Walkthru of FxA/Sync Account Creation

On Wed, Jan 8, 2014 at 3:19 PM, Mark Hammond wrote: > This means that once the user accidentally clicks somewhere, the panel > vanishes, the usual way of bringing the panel back doesn't work, and > indeed the current flows offer *no* way to bring it back at all (IIUC). I'm not too concerned about

Re: Walkthru of FxA/Sync Account Creation

al Message - > From: "Mark Finkle" > To: "Johnathan Nightingale" > Cc: "John Gruen" , "Gavin Sharp" , > sync-dev@mozilla.org > Sent: Wednesday, January 8, 2014 4:26:53 PM > Subject: Re: Walkthru of FxA/Sync Account Creation > >

Re: Walkthru of FxA/Sync Account Creation

On Wed, Jan 8, 2014 at 1:10 PM, John Gruen wrote: > - Original Message - >> From: "Johnathan Nightingale" >> To: "John Gruen" >> Cc: "Gavin Sharp" , sync-dev@mozilla.org >> Sent: Wednesday, January 8, 2014 4:01:23 PM >> Subject: Re: Wa

Re: Walkthru of FxA/Sync Account Creation

g.cgi?id=957436 is on file for this on desktop, and Mark's comment 0 understanding seems to similarly disagree.) Gavin - Original Message - > From: "John Gruen" > To: "Gavin Sharp" > Cc: sync-dev@mozilla.org > Sent: Wednesday, January 8, 201

Re: Implementation approaches for Create Account / Sign In

Good question. We have some experience localizing web content, but maybe not for a feature so closely tied to the browser. Web content often ends up being handled by separate localization teams, with different processes. I think web localization has also often historically been treated as "less imp

Re: What does "Client Implementation" mean?

On Fri, Aug 9, 2013 at 10:51 AM, Mark Finkle wrote: > We need to kill discussion of using Sync1.1 as it's a dead end. Using Sync > 2.0 is on the table, but we need to see more pros/cons I don't understand what "Using Sync 2.0" could mean. I've heard there is some existing server-side code for it.

Re: (decision) Re: Implementation approaches for Create Account / Sign In

On Mon, Aug 12, 2013 at 8:42 AM, Nick Alexander wrote: > I'm concerned that as we push the Firefox Account + Sync setup flow into the > first run experience, there is going to be an awkward jump from web content > to native (and even worse, possibly back for password reset). I'm not sure I unders

Re: Implementation approaches for Create Account / Sign In

I'm assuming we're talking about all of the screens on http://people.mozilla.com/~zfang/FirefoxAccount/PiCL_0710.pdf excluding "manage account" and "sign out". Using existing web content for that seems like a good idea to me. Getting the chrome/content interaction right (for the fundamentals like

Re: whats the key anyway?

On Sat, Jul 27, 2013 at 12:45 AM, Andreas Gal wrote: >> As a user, I expect that setting up Sync on my phone doesn't delete the data >> on my desktop or phone, instead merging everything together in a way that >> makes sense. > > Yep, thats exactly what we will do, except for black swan events, wh

Re: whats the key anyway?

On Sat, Jul 27, 2013 at 12:00 AM, Richard Newman wrote: > a background hum of user dissatisfaction. > a constant hiss of avoidable data loss. We can live with these if they're drowned out by a steady stream of users using and benefiting from Sync when they previously couldn't. (That's somewhat

Re: remote couchdb vs shadow database vs one database

On desktop, moving history+bookmarks from SQLite to CouchDB seems like a rather large undertaking. Gavin On Fri, Jul 26, 2013 at 1:30 PM, Andreas Gal wrote: > > Nobody is asking to move all core services. We are talking about history, > bookmarks and passwords, for now. > > Andreas > > > Mark Fi

Re: remote couchdb vs shadow database vs one database

On Fri, Jul 26, 2013 at 12:39 PM, Andreas Gal wrote: > You answered your own question. If I store passwords in a pouchdb > replacing the current storage (which is very desirable and would > greatly reduce complexity), and I am inside searchLogin() and I am > supposed to immediately return a login,

Re: remote couchdb vs shadow database vs one database

On Fri, Jul 26, 2013 at 11:53 AM, Andreas Gal wrote: > The main problem we are running into here > is that the password manager for example is completely synchronous. The API > is of the form x = searchLogin(needle). This can't be changed easily because > there is layers and layers of APIs around