954943 - Possible to add duplicate accounts

Status: NEW

(Chat Core :: General, defect)

Description

[Instantbot]

*** Original post on bio 1511 by Psykar <psyker7 AT gmail.com> at 2012-06-13 14:13:00 UTC ***

* Add a facebook account with username 'abcdefg' password 'abcdefg'
* This will fail to connect, but try to create a new account with the same details and it appears to succeed, with both accounts appearing in the accounts list.

I've tested the same with a few other protocols, same issue.

version 1.2a1pre (20120613042726) (1.2 is not in the version list)

Comment 1

[Benedikt Pfeifer]

*** Original post on bio 1511 at 2012-06-13 14:30:58 UTC ***

We definitely have a problem here with protocols based on Javascript and using "jsProtoHelper":
http://lxr.instantbird.org/instantbird/source/chat/modules/jsProtoHelper.jsm#715

(Method accountExists() is returning false in every case without actually checking for existance of an account.)

The affected protocols should be Facebook, GTalk and IRC while others should work fine. Thanks for reporting this!

Comment 2

[Benedikt Pfeifer]

*** Original post on bio 1511 at 2012-06-18 09:24:12 UTC ***

From what I saw the accountExists method is called with only the username but not the server for IRC. Will need to investigate this.

Comment 3

[Benedikt Pfeifer]

Attachment: Patch

*** Original post on bio 1511 as attmnt 1624 at 2012-06-18 10:47:00 UTC ***

OK, this should hopefully fix it.
The problem I mentioned above was actually with Gtalk and not IRC and had the reason that I had not thought of adding the _normalizeAccountName method to the Gtalk component yet.

Comment 4

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2012-06-18 10:57:51 UTC ***

Any reason for not changing:
http://lxr.instantbird.org/instantbird/source/chat/modules/jsProtoHelper.jsm#170

 69 const GenericAccountPrototype = {
[...]
170   get normalizedName() normalize(this.name),


To:
  get normalizedName() this.protocol._normalizeAccountName(this.name),

and then removing most get normalizedName() implementations in prpls?

Comment 5

[Patrick Cloke [:clokep]]

*** Original post on bio 1511 at 2012-06-19 01:57:39 UTC ***

Comment on attachment 8353381 [details] [diff] [review] (bio-attmnt 1624)
Patch

>diff --git a/chat/modules/jsProtoHelper.jsm b/chat/modules/jsProtoHelper.jsm
>@@ -663,16 +663,20 @@ ChatRoomFieldValues.prototype = {
> const GenericProtocolPrototype = {
>+  // _normalizeAccountName and the normalizedName-getter of the account proto-
>+  // type have to use the same method of normalization as the results will be
>+  // compared while checking for existing accounts.
>+  _normalizeAccountName: normalize,
>   get normalizedName() normalize(this.name),
Why not just use _normalizeAccountName here then?

>   getAccount: function(aImAccount) { throw Cr.NS_ERROR_NOT_IMPLEMENTED; },

>@@ -707,17 +711,26 @@ const GenericProtocolPrototype = {
>   // NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED errors are too noisy
Is this comment still applicable?

>-  accountExists: function() false, //FIXME
>+  accountExists: function(aName) {
>+    let accountEnum = Services.accounts.getAccounts();
>+    while (accountEnum.hasMoreElements()) {
>+      let acc = accountEnum.getNext();
>+      if (acc.protocol.id == this.id &&
>+          acc.normalizedName == this._normalizeAccountName(aName))
>+        return true;
>+    }
>+    return false;
>+  },
This looks good. :)

>diff --git a/chat/protocols/facebook/facebook.js b/chat/protocols/facebook/facebook.js
>@@ -40,16 +40,17 @@ FacebookAccount.prototype = {
> function FacebookProtocol() {
> }
> FacebookProtocol.prototype = {
>   __proto__: GenericProtocolPrototype,
>+  _normalizeAccountName: XMPPAccountPrototype._normalizeJID,
It seems weird to me that the protocol calls something on the account prototype...same goes for GMail, XMPP and IRC too. Also, would it make sense to have an XMPPProtocolPrototype? (I'm not sure if there are other duplicated properties.)

>diff --git a/chat/protocols/irc/irc.js b/chat/protocols/irc/irc.js
>@@ -1144,16 +1144,17 @@ function ircProtocol() {
>+  _normalizeAccountName: ircAccount.prototype.normalize,
This seems to be correct, yes.

>diff --git a/chat/protocols/twitter/twitter.js b/chat/protocols/twitter/twitter.js
>@@ -12,16 +12,18 @@ Cu.import("resource:///modules/jsProtoHe
>+function normalizeName(aName) aName.toLowerCase()

>@@ -334,16 +336,17 @@ function Account(aProtocol, aImAccount)
> Account.prototype = {
>+  get normalizedName() normalizeName(this.name),

>@@ -986,16 +989,17 @@ Account.prototype = {
> function TwitterProtocol() { }
> TwitterProtocol.prototype = {
>   __proto__: GenericProtocolPrototype,
>+  _normalizeAccountName: normalizeName,
It seems like this will work fine as Twitter IDs must match /\w{1,15}/.

Not sure if this is r+ or r- until some of my questions are answered. :)

Comment 6

[Benedikt Pfeifer]

Attachment: WIP

*** Original post on bio 1511 as attmnt 1747 at 2012-07-19 08:06:00 UTC ***

This WIP is not tested yet.

(In reply to comment #4)
> Any reason for not changing:
> http://lxr.instantbird.org/instantbird/source/chat/modules/jsProtoHelper.jsm#170
> 
>  69 const GenericAccountPrototype = {
> [...]
> 170   get normalizedName() normalize(this.name),
> 
> 
> To:
>   get normalizedName() this.protocol._normalizeAccountName(this.name),
> 
> and then removing most get normalizedName() implementations in prpls?

Done.


(In reply to comment #5)
> Comment on attachment 8353381 [details] [diff] [review] (bio-attmnt 1624) [details]
> Patch
> 
> >diff --git a/chat/modules/jsProtoHelper.jsm b/chat/modules/jsProtoHelper.jsm
> >@@ -663,16 +663,20 @@ ChatRoomFieldValues.prototype = {
> > const GenericProtocolPrototype = {
> >+  // _normalizeAccountName and the normalizedName-getter of the account proto-
> >+  // type have to use the same method of normalization as the results will be
> >+  // compared while checking for existing accounts.
> >+  _normalizeAccountName: normalize,
> >   get normalizedName() normalize(this.name),
> Why not just use _normalizeAccountName here then?

See above.

> >   getAccount: function(aImAccount) { throw Cr.NS_ERROR_NOT_IMPLEMENTED; },
> 
> >@@ -707,17 +711,26 @@ const GenericProtocolPrototype = {
> >   // NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED errors are too noisy
> Is this comment still applicable?

No idea. Flo, do you know that?

> >diff --git a/chat/protocols/facebook/facebook.js b/chat/protocols/facebook/facebook.js
> >@@ -40,16 +40,17 @@ FacebookAccount.prototype = {
> > function FacebookProtocol() {
> > }
> > FacebookProtocol.prototype = {
> >   __proto__: GenericProtocolPrototype,
> >+  _normalizeAccountName: XMPPAccountPrototype._normalizeJID,
> It seems weird to me that the protocol calls something on the account
> prototype...same goes for GMail, XMPP and IRC too.

I've followed flo idea now that suggested doing exactly that.

> Also, would it make sense to
> have an XMPPProtocolPrototype? (I'm not sure if there are other duplicated
> properties.)

XMPP is most likely the protocol that will see most other protocols based on it (we already ship two by default and there's LJ Talk and my VZ Netzwerke protocol plugins as extensions already). I don't think we want to duplicate this in each of them, so I would say we should create an XMPPProtocolPrototype that includes this and be done with it.

This WIP does NOT include such a change yet.

Comment 7

[Benedikt Pfeifer]

Comment on attachment 8353381 [details] [diff] [review]
Patch

*** Original change on bio 1511 attmnt 1624 at 2012-07-19 08:06:35 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 8

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2012-07-19 10:54:35 UTC ***

(In reply to comment #6)

> > >   getAccount: function(aImAccount) { throw Cr.NS_ERROR_NOT_IMPLEMENTED; },
> > 
> > >@@ -707,17 +711,26 @@ const GenericProtocolPrototype = {
> > >   // NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED errors are too noisy
> > Is this comment still applicable?
> 
> No idea. Flo, do you know that?

That comment was there to explain why we added a bunch of getters just returning always false, instead of not implementing them (getting something not implemented on a JS object would be undefined, converted to false, so not implementing works, but xpconnect throws noisy errors that I wanted to silence out).

That comment was meant to be above the long list of boolean attributes, so either move if there (ie before uniqueChatName) or just remove it, as we are no longer returning false for all of them anyway.

> > >diff --git a/chat/protocols/facebook/facebook.js b/chat/protocols/facebook/facebook.js
> > >@@ -40,16 +40,17 @@ FacebookAccount.prototype = {
> > > function FacebookProtocol() {
> > > }
> > > FacebookProtocol.prototype = {
> > >   __proto__: GenericProtocolPrototype,
> > >+  _normalizeAccountName: XMPPAccountPrototype._normalizeJID,
> > It seems weird to me that the protocol calls something on the account
> > prototype...same goes for GMail, XMPP and IRC too.
> 
> I've followed flo idea now that suggested doing exactly that.

Note that it's not really calling something on the account, but copying a reference to a function that happens to be defined on the object used as the prototype for accounts.

But I'm willing to take the blame for this weirdness. :)

> > Also, would it make sense to
> > have an XMPPProtocolPrototype?

I think it would be a good idea, but it's a bit out of the scope of this bug, so I wouldn't require this change to r+ a patch here.

> > (I'm not sure if there are other duplicated properties.)

I don't see anything duplicated between the Facebook chat and the Google Talk protocol prototypes.

Comment 9

[Benedikt Pfeifer]

Attachment: Patch

*** Original post on bio 1511 as attmnt 1756 at 2012-07-26 10:26:00 UTC ***

OK, I think I got it right this time. The patch is the same as the previous WIP + fixing the wrong function name in accountExists (for some reason I had "_normalizeName" instead of "_normalizeAccountName" in the WIP) and it worked as expected after that. I also removed the NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED comment.


About:
> > I've followed flo['s] idea now that suggested doing exactly that.

It seems I misremembered something here. I couldn't find any reference to where I thought you said that. Sorry.

Comment 10

[Benedikt Pfeifer]

Comment on attachment 8353507 [details] [diff] [review]
WIP

*** Original change on bio 1511 attmnt 1747 at 2012-07-26 10:26:22 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 11

[Patrick Cloke [:clokep]]

*** Original post on bio 1511 at 2012-08-15 19:15:05 UTC ***

I think this looks pretty good, do we care that you're normalizing the entire IRC ID (nick@server)? I'm not sure how this interacts with the weird "toLowerCase" IRC uses...should it be:
let [nick, server] = name.split("@");
ircAccount.prototype.normalize(nick)
server.toLowerCase()

Not saying this is right / worth the effort, just a concern.

Comment 12

[Patrick Cloke [:clokep]]

*** Original post on bio 1511 at 2012-08-15 19:31:02 UTC ***

(In reply to comment #9)
> server.toLowerCase()
I think you'd actually want https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIURI#equals%28%29 here (thanks to aleth for finding this)

Comment 13

[Benedikt Pfeifer]

*** Original post on bio 1511 at 2012-08-15 20:20:12 UTC ***

(In reply to comment #9)
> I think this looks pretty good, do we care that you're normalizing the entire
> IRC ID (nick@server)? I'm not sure how this interacts with the weird
> "toLowerCase" IRC uses...should it be:
> let [nick, server] = name.split("@");
> ircAccount.prototype.normalize(nick)
> server.toLowerCase()
> 
> Not saying this is right / worth the effort, just a concern.

No, this sounds reasonable. I'll adapt the comparison accordingly.

Comment 14

[Benedikt Pfeifer]

*** Original post on bio 1511 at 2012-08-18 13:15:16 UTC ***

(In reply to comment #10)
> (In reply to comment #9)
> > server.toLowerCase()
> I think you'd actually want
> https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIURI#equals%28%29
> here (thanks to aleth for finding this)

No, that won't work. The comparison is done by "accountExists()" in jsProtoHelper which knows nothing about the structure of an IRC account's name and therefoe can't extract the domains to compare them using the suggested "equals"-funtion. That's why we want the names in a normalized form, so that they can be compared without any additional information needed.

I'd do something like you suggested first instead (if there's a reason why I definitely should create an URI and extract the hostname (or whatever is needed) I'd be happy to hear about it) and attach a new patch if it's fine.

  _normalizeAccountName: function(aName) {
    let [nick, server] = aName.split("@");
    nick = ircAccount.prototype.normalize(nick);
    server = server.toLowerCase();
    return nick + "@" + server;
  },

Comment 15

[Patrick Cloke [:clokep]]

*** Original post on bio 1511 at 2012-08-20 12:04:59 UTC ***

(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > server.toLowerCase()
> > I think you'd actually want
> > https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIURI#equals%28%29
> > here (thanks to aleth for finding this)
> 
> No, that won't work. The comparison is done by "accountExists()" in
> jsProtoHelper which knows nothing about the structure of an IRC account's name

Then we can override it for IRC, no? I'm mostly concerned about using toLowerCase() if there are non-ASCII characters in the domain name.

Comment 16

[Patrick Cloke [:clokep]]

Comment on attachment 8353517 [details] [diff] [review]
Patch

*** Original change on bio 1511 attmnt 1756 at 2012-08-21 15:06:50 UTC ***

For the discussed reasons with IRC. Also I think we want to add a comment some where in jsProtoHelper (above _normalizeAccountName maybe? Or above accountExists or somewhere...) saying what people need to implement to avoid duplicate accounts.

Comment 17

[Benedikt Pfeifer]

Attachment: Patch v1

*** Original post on bio 1511 as attmnt 1963 at 2012-10-15 20:55:00 UTC ***

Another WIP-patch for this bug.
I added an own accountExists implementation for IRC, it compares the nromalized nicks and if the match, it uses uri's to compare the server names as well. This worked even fine when I created an account with unicode characters in its server name and tried to create another with the punycode equivalent of the name (which it refused since the account already existed).

Other parts *should* be OK, but I'll check first before putting this up for review.

Comment 18

[Benedikt Pfeifer]

Comment on attachment 8353517 [details] [diff] [review]
Patch

*** Original change on bio 1511 attmnt 1756 at 2012-10-15 20:55:49 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 19

[Benedikt Pfeifer]

Comment on attachment 8353722 [details] [diff] [review]
Patch v1

*** Original change on bio 1511 attmnt 1963 at 2012-10-24 14:46:15 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 20

[Benedikt Pfeifer]

*** Original post on bio 1511 at 2012-10-24 14:46:15 UTC ***

Comment on attachment 8353722 [details] [diff] [review] (bio-attmnt 1963)
Patch v1

I applied the patch again and tested the other changes too now. I didn't find any problems beside the following:

comparing domain names containing unicode-characters with their punycode encoding (only IRC uses this) doesn't always work. It seems to work with some letters (ä/ö/u) while it fails with others (ß/ø/œ). There might be other letters working or failing. I wouldn't expect it to be important. I don't know any IRC servers that are run on domains containing such letters and even if they are, the user would still need to try to setup an account twice with the unicode letters for one and the punycode name for the other. I doubt that anybody but me would try that :P

Comment 21

[Benedikt Pfeifer]

Comment on attachment 8353722 [details] [diff] [review]
Patch v1

*** Original change on bio 1511 attmnt 1963 at 2012-10-24 14:52:39 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 22

[Patrick Cloke [:clokep]]

Comment on attachment 8353722 [details] [diff] [review]
Patch v1

*** Original change on bio 1511 attmnt 1963 at 2012-10-24 15:03:41 UTC ***

(In reply to comment #14)
> Also I think we want to add a comment some
> where in jsProtoHelper (above _normalizeAccountName maybe? Or above
> accountExists or somewhere...) saying what people need to implement to avoid
> duplicate accounts.

Also, Florian will need to review the XMPP changes.

I'm still not thrilled about the whole _normalizeAccountName function, but I
can't think of a way to do it that's better...I almost wonder if we're trying to over abstract the wrong way. If we should add the method to jsProtoHelper that iterates over the accounts and takes a comparison function, then have each account call this with the comparison function. (Instead of having a magically named function on the account do something.)

Comment 23

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2012-10-27 03:34:59 UTC ***

Comment on attachment 8353722 [details] [diff] [review] (bio-attmnt 1963)
Patch v1

I looked over this briefly and didn't see anything wrong, but my attention level has already decreased significantly enough that I wouldn't r+ such a patch today at this point.

I do have a nit though: please remove the 4-space indent in the accountExists function in irc.js

Comment 24

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2012-11-02 00:22:43 UTC ***

If this is almost ready (it looks like it is) I think we can take it for 1.3.

Comment 25

[Benedikt Pfeifer]

Attachment: Patch v2

*** Original post on bio 1511 as attmnt 2032 at 2012-11-02 12:05:00 UTC ***

I added the comment (might need some tweaking most likely, maybe you want to check this first?) and moved two lines out of a loop that weren't necessary there in IRC's accountExists-implementation.

Comment 26

[Patrick Cloke [:clokep]]

Comment on attachment 8353792 [details] [diff] [review]
Patch v2

*** Original change on bio 1511 attmnt 2032 at 2012-11-02 12:25:01 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 27

[Patrick Cloke [:clokep]]

Comment on attachment 8353722 [details] [diff] [review]
Patch v1

*** Original change on bio 1511 attmnt 1963 at 2012-11-02 12:25:19 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 28

[Florian Quèze [:florian]]

Comment on attachment 8353792 [details] [diff] [review]
Patch v2

*** Original change on bio 1511 attmnt 2032 at 2012-11-02 22:38:51 UTC ***

I was about to r+ this as I think it looks OK overall, and is already a very significant improvement compared to the current state of the code, but then I noticed that Gtalk accounts aren't handled correctly (now that we support omitting the domain name of Gtalk accounts), and adding a special case for that would duplicated a third time the loop over the list of accounts, so I think that convinced me that clokep's suggestion in comment 17 is a better long term solution.

If you are out of time to make this change before 1.3, clokep offered to take it over.

Comment 29

[Patrick Cloke [:clokep]]

Comment on attachment 8353792 [details] [diff] [review]
Patch v2

*** Original change on bio 1511 attmnt 2032 at 2012-11-05 02:26:24 UTC ***

See flo's review comments. I think you're on the right track here (and have done a lot of the difficult part of figuring out what needs to be done for each protocol), but it needs bit more organization. :)

Comment 30

[Patrick Cloke [:clokep]]

*** Original post on bio 1511 at 2012-11-05 13:06:17 UTC ***

(In reply to comment #17)
> I'm still not thrilled about the whole _normalizeAccountName function, but I
> can't think of a way to do it that's better...I almost wonder if we're trying
> to over abstract the wrong way. If we should add the method to jsProtoHelper
> that iterates over the accounts and takes a comparison function, then have each
> account call this with the comparison function. (Instead of having a magically
> named function on the account do something.)

I'll expand on this comment a bit more, since it is confusing. In order to implement this, I would do the following:
1. Implement a basic "accountExists" on jsProtoHelper which iterates over the accounts and checks if the names using a comparison function that is input. accountExistsBase(aName, aComparison).
2. For each protocol, implement accountExists, which simply returns this.accountExistsBase(aName, function(aNameA, aNameB) { <do some comparison here> }).
3. Choose a better name than "accountExistsBase". :)
4. You can either have accountExists on jsProtoHelper throw an error about not being done, or have it implement a basic comparison (e.g. toLowerCase, like Twitter would use). I'd be OK with either of those solutions.

Comment 31

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2012-11-05 13:28:26 UTC ***

Ah, it's not how I understood comment 17. My understanding was that you wanted to have jsProtoHelper implement accountExists, and to have that implementation use an accountEquals (or any similar but better name) method of the same account, that would have a default implementation in jsProtoHelper, but could be easily overridden.

Comment 32

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2012-11-12 18:25:07 UTC ***

Too late for 1.3 (we plan to start building release candidates tomorrow, so we have only one nightly left; any regression caught tomorrow would delay the release at this point).

Comment 33

[Benedikt Pfeifer]

Attachment: WIP3

*** Original post on bio 1511 as attmnt 2092 at 2012-11-16 16:56:00 UTC ***

Latest WIP (WIP3): it's failing in |accountExists| because |accountEquals| isn't existing on the prplAccount interface and therefore not on the objects returned by the enumerator. |wrappedJSObject| doesn't exist on the enumerated accounts and using the |wrappedJSObject| of the prplAccount property doesn't work either. As a consequence the whole thing is untested.

Feedback on the XMPPAccountPrototype's accountEquals implementation with the "default servers" would be appreciated.

Things to do: get it to work; compare the domains in account names for XMPP as done for IRC (using nsURI.equals);


It was suggested to add |accountEquals| to the prplAccount interface which would require an implementation in purplexpcom too. Help on this / a decision how to proceed best would be great! :)

Comment 34

[Benedikt Pfeifer]

Comment on attachment 8353853 [details] [diff] [review]
WIP3

*** Original change on bio 1511 attmnt 2092 at 2012-11-16 16:57:05 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 35

[aleth [:aleth]]

*** Original post on bio 1511 at 2012-11-16 19:31:37 UTC ***

I've not tested the whole patch, but I tried it for IRC and it worked well with

if (acc.protocol.id == this.id &&
    acc.prplAccount.wrappedJSObject.accountEquals(aName))

Comment 36

[Patrick Cloke [:clokep]]

Comment on attachment 8353853 [details] [diff] [review]
WIP3

*** Original change on bio 1511 attmnt 2092 at 2012-11-18 19:38:34 UTC ***

I'm good with these changes (and with the IRC implementation), I'll leave the XMPP implementation to Florian.

Comment 37

[aleth [:aleth]]

*** Original post on bio 1511 at 2013-04-09 14:50:14 UTC ***

Does this look so close to finished that it might fit into 1.4?

Comment 38

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2013-04-09 17:16:28 UTC ***

(In reply to comment #29)
> Does this look so close to finished that it might fit into 1.4?

yes.

Comment 39

[Florian Quèze [:florian]]

Comment on attachment 8353853 [details] [diff] [review]
WIP3

*** Original change on bio 1511 attmnt 2092 at 2013-09-12 18:41:59 UTC ***

>+  accountExists: function(aName) {
>+    let accountEnum = Services.accounts.getAccounts();
>+    while (accountEnum.hasMoreElements()) {
>+      let acc = accountEnum.getNext();
>+      if (acc.protocol.id == this.id && acc.accountEquals(aName))

This code assumes that accountEquals exists on all accounts. Do you need help to implement it in purplexpcom?


>+  accountEquals: function(aName, aDefaultServers /* optional */) {
>+    if (!aDefaultServers  || aDefaultServers.length == 0)
>+      return this.normalizedName == this._normalizeJID(aName);
>+
>+    const createJIDsFromName = function(aName, aDefaultServers) {
>+      let results = [];
>+      let jid = this._parseJID(aName);
>+      if (jid.node)
>+        results.push(jid);
>+      else {

Shouldn't we also go into this case if the user has entered as part of the username a domain name that's part of the default domain list?

>+        // The XMPP spec says that the node part of a JID is optional and we
>+        // parse the JID accordingly. Since we've got a list of default servers,
>+        // we assume instead that the domain was omitted. Our node is what was
>+        // parsed into jid.domain then.
>+        aDefaultServers.forEach(function(s) {
>+          results.push(jid.domain + "@" + s.toLowerCase());
>+        });
>+      }
>+      return results;
>+    }

Nit: missing ;

Comment 40

[Patrick Cloke [:clokep]]

*** Original post on bio 1511 at 2013-11-06 17:33:10 UTC ***

Any chance of getting this done for 1.5? :)

Comment 41

[Florian Quèze [:florian]]

*** Original post on bio 1511 at 2013-11-22 07:03:47 UTC ***

(In reply to comment #32)
> Any chance of getting this done for 1.5? :)

Looks like not :(.

Comment 42

[Benedikt Pfeifer]

Mass-removing myself from being assignee of any Chat related bug as I'm no longer active.