Sync account creation or device pairing fails with exception in BrowserIDManager

NEW
Unassigned

Status

SeaMonkey
Sync UI
3 years ago
a month ago

People

(Reporter: rsx11m, Unassigned)

Tracking

(Blocks: 1 bug, {regression, relnote})

Trunk
regression, relnote

SeaMonkey Tracking Flags

(seamonkey2.26 affected, seamonkey2.27 affected, seamonkey2.28 affected, seamonkey2.29 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
(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
(Reporter)

Updated

3 years ago
Summary: Account creation or device pairing fails with exception in BrowserIDManager → Sync account creation or device pairing fails with exception in BrowserIDManager
Just filed bug 1003434 for an issue I discovered. Maybe the second part (404) is related to the removals on the Mozilla website side.
(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).
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...
status-seamonkey2.26: --- → affected
status-seamonkey2.27: --- → affected
status-seamonkey2.28: --- → affected
status-seamonkey2.29: --- → affected
Keywords: regressionwindow-wanted → relnote
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.
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.
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.
Blocks: 1003434

Updated

3 years ago
Duplicate of this bug: 1041117
(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

3 years ago
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?
Flags: needinfo?(jh)

Comment 10

3 years ago
Is there any idea when this bug will be fixed?
Created attachment 8523515 [details] [diff] [review]
Patch (workaround)

Updated

3 years ago
Attachment #8523515 - Attachment description: Path (workaround) → Patch (workaround)
(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.
Flags: needinfo?(jh)
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1108240

Comment 14

2 years ago
Please fix it, really annoying.
Since 1 Month i have to use chrome with a working sync.

Comment 15

2 years ago
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?
Duplicate of this bug: 1137038

Comment 17

2 years ago
I'm surprised this is not fixed yet. Guess I'll be stuck with version 2.25 for a while.

Comment 18

2 years ago
11 month later still not work in 2.33?
What is the problem with sync?
(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).
(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.
(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)
(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?
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?

Comment 24

2 months ago
Hello,

I had trouble setting up my existing sync with my own custom sync server after I installed seamonkey on a new computer. Sometimes it worked but many times it did not very frustrating but I found a way to set it up with out errors.

Here is how I managed to set it up:

Go to the setup sync window and get to the part where you can enter your existing key username and choose the sync server. 

Enter your key at the bottom
Enter your user name/email at the top. 
Now click in the password field and copy / paste your password and make SURE you do NOT copy a new line or enter or press TAB or ENTER or do anything else (This is the important part!)
Now CLICK on the pulldown menu and select "custom server"
I pasted my customer server without a new line or enter
Now the next botton became available without the error messaage in the console and pressing next actually worked.
You should see the "verifying .. " message.

I think that when the password field looses focus by clicking an other text field it triggers some kind of check that is no longer available and just stops (basicPassword setter).  But when it looses focus when you click on the pulldown it just skips this check and unlocks the verify button and apparently submits the  password anyway because it works afterwards. 

Once I discovered this I tried it several times and I could set up my sync each time. 

So I think the only thing that needs to be done to fix this old problem is to find and remove the part that triggers the "basicPassword setter in BrowserIDManager". It is not needed anyway. I should be very easy for a developer. 

Maybe it also fixes creating a new account on a custom server.
You need to log in before you can comment on or make changes to this bug.