Last Comment Bug 998807 - Sync account creation or device pairing fails with exception in BrowserIDManager
: Sync account creation or device pairing fails with exception in BrowserIDManager
Status: NEW
: regression, relnote
Product: SeaMonkey
Classification: Client Software
Component: Sync UI (show other bugs)
: Trunk
: All All
-- normal with 21 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 1041117 1108240 1137038 (view as bug list)
Depends on:
Blocks: 1003434
  Show dependency treegraph
 
Reported: 2014-04-20 13:28 PDT by rsx11m
Modified: 2017-02-17 09:35 PST (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
affected
affected
affected
affected


Attachments
Patch (workaround) (1.17 KB, patch)
2014-11-16 05:47 PST, Frank Wein [:mcsmurf]
no flags Details | Diff | Splinter Review

Description User image rsx11m 2014-04-20 13:28:45 PDT
(Quoting rsx11m from bug 993847 comment #15)
> I've created the Sync account with a Firefox release build (which worked
> flawlessly) and then tried to connect SeaMonkey trunk by pairing with that
> 3-group/4-character key. This gave me the following:
> 
> Error: [Exception... "basicPassword setter should be not used in
> BrowserIDManager'basicPassword setter should be not used in
> BrowserIDManager' when calling method: [nsIRunnable::run]"  nsresult:
> "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "native frame ::
> <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]

This still works in 2.25 but is broken in current nightly builds.

Account creation ends up with a similar log message and a failed server response after the e-mail address has been entered:

(Quoting rsx11m from bug 993847 comment #14)
> Error: Unknown response from server: <html>
>   <head>
>    <title>404 Not Found</title>
>   </head>
>   <body>
>    <h1>404 Not Found</h1>
>    The resource could not be found.<br /><br />
>   </body>
> </html>
> Source File: resource://services-sync/userapi.js
> Line: 143
Comment 1 User image Jens Hatlak (:InvisibleSmiley) 2014-04-29 13:41:03 PDT
Just filed bug 1003434 for an issue I discovered. Maybe the second part (404) is related to the removals on the Mozilla website side.
Comment 2 User image Jens Hatlak (:InvisibleSmiley) 2014-05-02 05:34:44 PDT
(In reply to rsx11m from comment #0)
> basicPassword setter should be not used in BrowserIDManager

This is coming from here:
http://mxr.mozilla.org/comm-central/source/mozilla/services/sync/modules/browserid_identity.js#345

BrowserIDManager is used because of this check:
http://mxr.mozilla.org/comm-central/source/mozilla/services/sync/modules/status.js#31

The check depends on service.fxAccountsEnabled which is here:
http://mxr.mozilla.org/comm-central/source/mozilla/services/sync/Weave.js#100

Which returns true (= use FxAccounts) iff old Sync has not been set up.

=> We're dead.

NB: What has been implemented is of course in line with what the FF guys want (prevent people from setting old Sync accounts anew).
Comment 3 User image Jens Hatlak (:InvisibleSmiley) 2014-05-02 05:44:41 PDT
The above was introduced with bug 959222 (among others) which has TM FF 29, i.e. SM 2.26 is already affected. I'll add something to the release notes...
Comment 4 User image Frank Wein [:mcsmurf] 2014-05-06 07:34:31 PDT
So looks like this this is indirectly some bug in the services/sync/ code? Or well, maybe initional behaviour, not sure. After all the UI should make sure the correct account type gets created? Or is the code mentioned in Comment 3 responsible for choosing the correct account type? Then things get a bit more difficult.
Comment 5 User image Jens Hatlak (:InvisibleSmiley) 2014-05-06 13:15:51 PDT
Basically the FF guys decided to disable setting up legacy Sync, and part of that happened in shared back-end code (below services/) instead of only in the front-end. To them it doesn't really matter since they promote and already provide the new Sync setup in FF. But for us it means we're dead already on that end and not only once legacy Sync gets killed completely.

Maybe setting the pref services.sync.username to "@" temporarily works - that tweak could however break more than it fixes.

If we're desperate enough, I guess we could also hack around it, like so:

var WS = Components.classes["@mozilla.org/weave/service;1"].getService(Components.interfaces.nsISupports).wrappedJSObject;
WS.__defineGetter__("fxAccountsEnabled", function() false);

WS.fxAccountsEnabled will then always return false (currently it only does if legacy Sync has already been set up, i.e. not in the Sync setup case).

Of course that ugly hack could break any time they make further changes, and it's not guaranteed this hack is enough to get us going again.

In the end the only real way forward is implementing the new Sync setup.
Comment 6 User image Jens Hatlak (:InvisibleSmiley) 2014-05-12 12:18:56 PDT
Setting this bug as a dependency for bug 1003434 so it doesn't get lost. Though technically both are mostly unrelated, fixing the other one is hardly any use until this one gets fixed.
Comment 7 User image Frank Wein [:mcsmurf] 2014-07-19 07:22:30 PDT
*** Bug 1041117 has been marked as a duplicate of this bug. ***
Comment 8 User image Frank Wein [:mcsmurf] 2014-07-21 16:31:01 PDT
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #5)
> Basically the FF guys decided to disable setting up legacy Sync, and part of
> that happened in shared back-end code (below services/) instead of only in
> the front-end. To them it doesn't really matter since they promote and
> already provide the new Sync setup in FF. But for us it means we're dead
> already on that end and not only once legacy Sync gets killed completely.
> 
> Maybe setting the pref services.sync.username to "@" temporarily works -
> that tweak could however break more than it fixes.

Actually we need to set the username to something else than "@" (e.g. "_"), then it seems to work fine.
Comment 9 User image Edmund Wong (:ewong) 2014-11-14 17:56:07 PST
Assuming this is fixed, 1.1 sync account creation needs a change. The captcha
server has been turned off.  

Should we use a different captcha server or just remove the captcha wizard
in the setup ui?
Comment 10 User image destinthegreat 2014-11-15 14:17:51 PST
Is there any idea when this bug will be fixed?
Comment 11 User image Frank Wein [:mcsmurf] 2014-11-16 05:47:42 PST
Created attachment 8523515 [details] [diff] [review]
Patch (workaround)
Comment 12 User image Jens Hatlak (:InvisibleSmiley) 2014-11-16 13:20:27 PST
(In reply to Edmund Wong (:ewong) from comment #9)
> Assuming this is fixed, 1.1 sync account creation needs a change. The captcha
> server has been turned off.  
> 
> Should we use a different captcha server or just remove the captcha wizard
> in the setup ui?

I think we don't want to offer legacy Sync account creation at all anymore if it doesn't work / isn't supported. Don't put any effort in trying to keep up something that's destined to die here. Let's use our limited time as effectively as possible.
Comment 13 User image rsx11m 2014-12-06 09:04:55 PST
*** Bug 1108240 has been marked as a duplicate of this bug. ***
Comment 14 User image Peter Rottmann 2015-01-14 08:28:05 PST
Please fix it, really annoying.
Since 1 Month i have to use chrome with a working sync.
Comment 15 User image Roger Davis 2015-02-12 12:27:23 PST
This is a critical problem for me.  We have 5 machines relying on sync, which now doesn't sync.  What it the schedule to fix this major bug?
Comment 16 User image Jens Hatlak (:InvisibleSmiley) 2015-02-25 22:26:07 PST
*** Bug 1137038 has been marked as a duplicate of this bug. ***
Comment 17 User image Nina T 2015-03-15 11:29:31 PDT
I'm surprised this is not fixed yet. Guess I'll be stuck with version 2.25 for a while.
Comment 18 User image Peter Rottmann 2015-03-23 08:14:29 PDT
11 month later still not work in 2.33?
What is the problem with sync?
Comment 19 User image Edmund Wong (:ewong) 2015-04-14 17:13:01 PDT
(In reply to Peter Rottmann from comment #18)
> 11 month later still not work in 2.33?
> What is the problem with sync?

The Sync that works with 2.25 is v1.1 which is not working
with 2.26+ because there has been changes in the
backend such that 1.1 can only work with some fudging.

Unfortunately, Sync v1.5 is unavailable for us to use
because the SeaMonkey project isn't allowed to use
FxAccounts which is what Sync v1.5 requires.

Perhaps comment #8 might help you workaround this problem?

As for the solution to Sync, it's my understanding that
we should go for Sync v1.5.  However, we need our own
Sync v1.5 server (and this brings along a host of other
issues).
Comment 20 User image S P Arif Sahari Wibowo 2015-09-09 04:25:22 PDT
(In reply to Edmund Wong (:ewong) from comment #19)
> Unfortunately, Sync v1.5 is unavailable for us to use
> because the SeaMonkey project isn't allowed to use
> FxAccounts which is what Sync v1.5 requires.

Would you mind to explain this further (or point to such explanation)?
- Is the SeaMonkey forbidden even to have mechanism that make it possible to use FxAccounts? Can it be done through Extension?
- Is Sync v1.5 require FxAccounts is its actual operation, or just on initial setup?

> As for the solution to Sync, it's my understanding that
> we should go for Sync v1.5.

Agreed, the code may disappear altogether in the future. Added to that, Mozilla has been reminding users that it plans to shut down its Sync v1.1 server by the end of this year. I think most people that use Sync were just using Mozilla's server and therefore the shut down will basically stop SeaMonkey's Sync functionality altogether, if no other alternatives are built.

> However, we need our own
> Sync v1.5 server (and this brings along a host of other
> issues).

I agree this brings other issue. Maybe you don't need to. Instead, just make sure it is easier for people to setup their own server (more practical and straightforward documentation, wrapper code, etc.). Therefore, some users will just setup their own server, some may even provide it for others.
Comment 21 User image Edmund Wong (:ewong) 2015-09-09 18:26:04 PDT
(In reply to S P Arif Sahari Wibowo from comment #20)
> (In reply to Edmund Wong (:ewong) from comment #19)
> > Unfortunately, Sync v1.5 is unavailable for us to use
> > because the SeaMonkey project isn't allowed to use
> > FxAccounts which is what Sync v1.5 requires.
> 
> Would you mind to explain this further (or point to such explanation)?
> - Is the SeaMonkey forbidden even to have mechanism that make it possible to
> use FxAccounts? Can it be done through Extension?
> - Is Sync v1.5 require FxAccounts is its actual operation, or just on
> initial setup?

It seems as if there's a change in policy or some such and the SeaMonkey
project is now allowed to use FxAccounts and the Sync 1.5 servers.   
So now all we need is someone to get the sync code ported.



> 
> > However, we need our own
> > Sync v1.5 server (and this brings along a host of other
> > issues).
> 
> I agree this brings other issue. Maybe you don't need to. Instead, just make
> sure it is easier for people to setup their own server (more practical and
> straightforward documentation, wrapper code, etc.). Therefore, some users
> will just setup their own server, some may even provide it for others.

There is a page up on wiki (I think) that 'describes' how to setup a Sync 1.5 server.  While I got it working eventually,  I didn't find it any bit straightforward. (well perhaps I'm just a little dull in the brain)
Comment 22 User image S P Arif Sahari Wibowo 2015-10-02 19:37:34 PDT
(In reply to Edmund Wong (:ewong) from comment #21)
> It seems as if there's a change in policy or some such and the SeaMonkey
> project is now allowed to use FxAccounts and the Sync 1.5 servers.   

Indeed iCab Mobile apparently now can read into Firefox sync data, both 1.1 and 1.5.

> So now all we need is someone to get the sync code ported.

That will be bug 1022319, right? Unfortunately does not seem to be much progress there.

> There is a page up on wiki (I think) that 'describes' how to setup a Sync
> 1.5 server.  While I got it working eventually,  I didn't find it any bit
> straightforward. (well perhaps I'm just a little dull in the brain)

Yeah, I can see that. Therefore if it can be made easier, it will probably helps.

BTW, today I cannot seems to connect to Mozzila's Sync 1.1. server. Maybe it has been turned off?
Comment 23 User image Andrey ``Bass'' Shcheglov 2017-02-17 05:31:33 PST
Since Mozilla will eventually pull the plug on their v1.1 Sync servers, is it possible to use the Pale Moon servers with SeaMonkey?

Using older SeaMonkey versions (e.g.: 2.7), it was possible to change services.sync.serverURL from https://auth.services.mozilla.com/ to https://pmsync.palemoon.net/sync/index.php/ and easily link SeaMonkey to an existing Pale Moon sync account (this is how I sync my Debian IceApe (rebranded SM 2.7) with Pale Moon).

It doesn't seem possible any more with modern SM versions: when I choose "I already have a SeaMonkey Sync" account, enter the username, password and recovery key and press "Next" -- nothing happens (no change of the UI, no error message, no HTTP(S) packets sent to pmsync.palemoon.net).

How do I set up Sync (v1.1) in SeaMonkey, provided I already have an account?

Note You need to log in before you can comment on or make changes to this bug.