User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29a1 (Beta/Release) Build ID: 20140607003001 Steps to reproduce: In the near future the old sync will be decommissioned (bug 1008066). Before this happens SeaMonkey needs to switch to the new sync system to provide this feature in future too.

Since Firefox 32, Sync 1.0/1.1 are not available anymore in Firefox, using Firefox Accounts is required (FxA), then it becomes impossible to keep syncing Firefox profiles with SeaMonkey profiles https://wiki.mozilla.org/User_Services/Sync https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/ the transition in Firefox as an end user scenario had been described here https://wiki.mozilla.org/User_Services/Sync/Relaunch Original plan was to drop support in Firefox 31, and was eventually implemented in Firefox 32 (sorry but I can't find again explicit documentation about this) Meta tracking bug for FxA in release 29 is bug 969593 Looks like a very serious bug to me

Olivier, the situation is known and understood. What the SeaMonkey team needs is someone to actually do the work. If you are able to help or know someone who wants to contribute, any help for actually doing the porting of the code would be appreciated. SeaMonkey is an all-volunteer project, so it's dependent on people volunteering to do the work.

Robert, thanks for acknowledging this and changing status to NEW No, I don't have the knowledge required to handle any type of coding in SeaMonkey My workaround for the moment as a user is: - if you have upgraded to Firefox 32 and don't see your Sync settings anymore, un-install and go back to FF 28 - Launch FF 28 at least once, check that you sync settings are fine, quit - Install FF 31 instead of FF 28, and uncheck automatic upgrades, don't install Mozilla Maintenance Service, and cross fingers not getting automatically upgraded to FF 32 (it keeps happening to me every 3-4 days) Additional drawback is that FF on Android is FF 32, then you can't sync with the mobile version for the moment Maybe is it possible to setup a given version of FF on Android ? How ?

I've been looking at the Fx sync code and realized a few things. 1) Implementing the new 1.5 Sync stuff requires porting the aboutaccounts.*(et.al) code. I can't hack the old Sync setup xul stuff to interface with the 1.5 servers. 2) aboutaccounts.xhtml has an iframe that's remote content (connects to accounts.firefox.com iirc) that does the account creation et. al. - 'problem' with this is that after you click "Get Started" in the firefox aboutaccounts.xhtml page, it brings you to the remote content which says "Create a Firefox Account" (and all those related to the Firefox brand). - that branding can't be changed since it is remote content, but since Firefox Accounts is the actual brand name, I guess it can't be fixed. I'm guessing this requirement of us using aboutaccounts.* (et. al) is because the remote content would be local to the server and thusly wouldn't have traffic coming and going from the Sync setup UI to the server (if a new Sync setup UI was created). Was told by :markh on irc that it has to be done locally on that server. So unless we implement our own server i.e. accounts.seamonkey-project.org (or whatever), we'll need to use Fx's server.

A few items that I just want to jot down (and possibly get an opinion): (Since I'm a bit more comfortable with Preferences, I think I'll have a go at the preferences part first, though, like most preference placement, this is potential bikeshedding territory. ;P ) - We'll need both v1.1 and 1.5 Sync Preferences. Right now, we have in Preferences: - Sync I'm wondering if I should do?: - Sync - 1.1 - 1.5 or: - Sync [in Sync preferences, have it in tabs..i.e. [v1.1] [v1.5] Once 1.1 is phased out/obsoleted, we can remove 1.1 stuff? I'm wondering if it's possible to have concurrently opened Sync accounts(but different version #)? Jens, what's your opinion?

(In reply to Edmund Wong (:ewong) from comment #4) > - that branding can't be changed since it is remote content, but since > Firefox Accounts is the actual brand name, I guess it can't be fixed. I think we need to live with the fact that it's called "Firefox Account". It's being used with a number of services and it is one account for all the things, so the branding is pretty much set in stone. Also, if people already have a Firefox Account, they can just use it with SeaMonkey. I know it might be confusing, but we should just live with it. (In reply to Edmund Wong (:ewong) from comment #5) > - We'll need both v1.1 and 1.5 Sync Preferences. Erm, why? I don't think we should continue to have 1.1 exposed when 1.5 support is in. Esp. as 1.1 support will be going away in Gecko soon, we should just get rid of the prefs for it.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6) > (In reply to Edmund Wong (:ewong) from comment #4) > > - that branding can't be changed since it is remote content, but since > > Firefox Accounts is the actual brand name, I guess it can't be fixed. > > I think we need to live with the fact that it's called "Firefox Account". > It's being used with a number of services and it is one account for all the > things, so the branding is pretty much set in stone. Also, if people already > have a Firefox Account, they can just use it with SeaMonkey. > I know it might be confusing, but we should just live with it. > It's the confusion that I'm concerned about. > (In reply to Edmund Wong (:ewong) from comment #5) > > - We'll need both v1.1 and 1.5 Sync Preferences. > > > Erm, why? I don't think we should continue to have 1.1 exposed when 1.5 > support is in. Esp. as 1.1 support will be going away in Gecko soon, we > should just get rid of the prefs for it. Well basically, there's still users who use 1.1 Sync and removing the 1.1 prefs wouldn't be a good idea (IMO). We'd have to really wait for 1.1 servers to die before we can remove these prefs. (That's my take on this.)

First of all I don't think doing prefs UI first is the right approach. Sure it's the easiesr part, but if the rest won't get done, what's the point? Regarding Sync versions to cover in Preferences, I think we'd need to detect which version the user is using, i.e. if legacy Sync has already been set up, show it (together with a note that one should upgrade ASAP). I feel the user should be able to see the current configuration, e.g. which email address s/he used or which items were selected for synchronization. If Sync has not been set up yet, or new Sync is active, show the new prefs. With that in mind there's never a need to show both legacy and new Sync at the same time, except for the ability to set up new Sync which legacy Sync is still active of course. If the decision was taken to completely drop legacy Sync support on our side, or if support for it was dropped in shared code (which could happen any time now), I wouldn't be opposed to only implement new Sync support, including the prefs UI side. But again I think that shouldn't be the first thing to care about.

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #8) > First of all I don't think doing prefs UI first is the right approach. Sure > it's the easiesr part, but if the rest won't get done, what's the point? I might have been very unclear on my intention. My point was to do the prefs first then do the actual Sync 1.5 'port'. > > Regarding Sync versions to cover in Preferences, I think we'd need to detect > which version the user is using, i.e. if legacy Sync has already been set > up, show it (together with a note that one should upgrade ASAP). I feel the > user should be able to see the current configuration, e.g. which email > address s/he used or which items were selected for synchronization. > > If Sync has not been set up yet, or new Sync is active, show the new prefs. > > With that in mind there's never a need to show both legacy and new Sync at > the same time, except for the ability to set up new Sync which legacy Sync > is still active of course. Exactly my thoughts. Allow the user to have both 1.1 and 1.5 active and then have an option such that the user can then disable 1.1. > > If the decision was taken to completely drop legacy Sync support on our > side, or if support for it was dropped in shared code (which could happen > any time now), I wouldn't be opposed to only implement new Sync support, > including the prefs UI side. But again I think that shouldn't be the first > thing to care about. I understand. In Fx, they have users go to aboutaccounts.xhtml to create accounts. I find it 'jarring' to click on a XUL setup UI button to be sent to an XHTML file. Is it possible to create an iframe within a XUL file? (I'm thinking along the lines of what we do with the captcha thingy in our old sync setup UI.)

All the voices produce lots of confusion to me. Apparently the path is open to use the FF sync, the problem is how to migrate? Produce a conversion executable, copy bookmarks and/or other files to another location, run the conversion, drop the produced file back on top of the original, done? If the local files are the same, but the sync is different, this could be invisible to the user, except to announce that to make sync work, you must upgrade to SeaMonkey XX.xx on all local machines using sync. Do something, even if it's not conceptually perfect, as long as it works.

FWIW, Firefox supports showing (and editing) setting for old sync and new sync, it just doesn't tell you in any obvious way which one you are using and it doesn't have anything for switching at this point - but the migration of users from old to new will start in the current Nightly version (37) with a small set of users to test the migration process.

Content-less comments will not help getting this fixed. SeaMonkey is a community project consisting entirely of volunteers. Only trying to actually work on patches will help getting this fixed.

Kairo, sorry to annoy you. Sorry I can't do the needed code writing. But, I believe we just wanted to let you know of our enduring interest. I don't see any SeaMonkey forums to voice this interest. Does XMarks or another program sync bookmarks between Firefox and SeaMonkey?

I'm happy to help where I can here, but don't know enough about SeaMonkey. Can someone summarize what differences existed in Sync between SeaMonkey and Firefox *before* the FxA support landed in Fx29 or so? I had the impression that the code was largely unchanged until then, which if true means this should be quite easy to fix. It's worth noting that we hope to turn off the sync 1.1 servers in just a few months...

(In reply to Mark Hammond [:markh] from comment #16) > Can someone summarize what differences existed in Sync between SeaMonkey and > Firefox *before* the FxA support landed in Fx29 or so? From what I understand, the biggest issue is that the SeaMonkey team was told that it could not point to Mozilla's FxA or Sync 1.5 servers and so needs to figure out how to set up infrastructure itself and how to make it easy enough for people to use that for syncing SeaMonkey to Firefox desktop/Android, which is that #1 use case for using Sync in SeaMonkey at all.

Hmm: https://blog.mozilla.org/services/2015/07/31/shutting-down-the-legacy-sync-service/ What will happened now with SM-sync? Andreas

The recent update for iCab mobile (8.10 iOS) added support for Sync 1.5 (only reading at the moment). So shouldn't this be possible for SeaMonkey too?

(In reply to rocking.man from comment #19) > The recent update for iCab mobile (8.10 iOS) added support for Sync 1.5 > (only reading at the moment). So shouldn't this be possible for SeaMonkey > too? Yes, it is. The issue is with the resource availability of getting it done.

(In reply to Andreas Fenner from comment #18) > https://blog.mozilla.org/services/2015/07/31/shutting-down-the-legacy-sync-service/ As promised, Mozilla's Sync 1.1 server stop working today. I guess that means for most users Seamonkey sync feature stop working as well.

Sorry it has taken so long, but I can confirm that SeaMonkey has permission to offer users Firefox Accounts and to use Mozilla's Firefox Accounts and Sync infrastructure. While Mozilla can't offer resources to make this actually happen, we'd like to reserve the right to review the code (including the UI) before it lands. In particular, we would want to make sure that it is made clear to SeaMonkey users that they're signing up for a Firefox Account with Mozilla, so their data will be housed on Mozilla servers, and that the integration is sane in that it will not cause unexpected issues with that infrastructure. You can needinfo? me to help find the right people for these reviews when the time comes. Please let me know if you need any further information or additional clarification.

(In reply to Mark Hammond [:markh] from comment #22) > Sorry it has taken so long, but I can confirm that SeaMonkey has permission > to offer users Firefox Accounts and to use Mozilla's Firefox Accounts and > Sync infrastructure. While Mozilla can't offer resources to make this > actually happen, we'd like to reserve the right to review the code > (including the UI) before it lands. In particular, we would want to make > sure that it is made clear to SeaMonkey users that they're signing up for a > Firefox Account with Mozilla, so their data will be housed on Mozilla > servers, and that the integration is sane in that it will not cause > unexpected issues with that infrastructure. You can needinfo? me to help > find the right people for these reviews when the time comes. > > Please let me know if you need any further information or additional > clarification. Nice! Thanks for the info. I guess someone will be hassling you guys soon enough with the implementation.. :)

I'd like to thank the SeaMonkey team for "doing the right thing" by clearing permission for FxA integration, and sincerely apologize you were punished by IMO a substantial delay in us being able to clear that approval in timely manner.