*** Original post on bio 661 at 2011-01-23 15:07:00 UTC *** For libpurple accounts the protocol does not handle setting the containsNick field, it is set automatically by the chat [1]. Something similar should be done for JavaScript protocols -- I've already written the code for this part, but we need to add <chat>.nick to the purpleIConvChat interface [2]. [1] http://lxr.instantbird.org/instantbird/source/purple/libpurple/conversation.c#1572 [2] http://lxr.instantbird.org/instantbird/source/purple/purplexpcom/public/purpleIConversation.idl#127

*** Original post on bio 661 at 2011-01-23 15:08:31 UTC *** I have an upcoming patch for the jsProtoHelper part of this.

*** Original post on bio 661 as attmnt 496 at 2011-01-24 04:18:00 UTC *** This part handles what needs to be added to jsProtoHelper, the commented out line is how I would prefer to do this...but it doesn't work, I think the "this" arg might be wrong, but I also tried using <...>.call(this, <...> and it still didn't work. I would need some guidance to edit the interface.

*** Original post on bio 661 as attmnt 497 at 2011-01-24 05:02:00 UTC *** Mook helped me out a bit on IRC and this automatically calls the __proto__ message now. It's a little confusing so I included comments based on Mook's explanation, hopefully they still make sense.

Comment on attachment 8352239 [details] [diff] [review] jsProtoHelper v1.0 *** Original change on bio 661 attmnt 496 at 2011-01-24 05:02:35 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment on attachment 8352240 [details] [diff] [review] jsProtoHelper Patch v2.0 *** Original change on bio 661 attmnt 497 at 2011-01-24 10:34:26 UTC *** >diff --git a/purple/purplexpcom/src/jsProtoHelper.jsm b/purple/purplexpcom/src/jsProtoHelper.jsm >--- a/purple/purplexpcom/src/jsProtoHelper.jsm >+++ b/purple/purplexpcom/src/jsProtoHelper.jsm >@@ -526,6 +526,24 @@ > Object.keys(this._participants) > .map(function(key) this._participants[key], this) > ); >+ }, >+ >+ writeMessage: function convChatWriteMessage(aWho, aText, aProperties) { >+ // Check if the message contains our nick >+ aProperties.containsNick = (aText.indexOf(this.nick) != -1); Do we want to write the containsNick property all the time, or let it fall back to the value in the prototype when we haven't found the nick? I know I suggested this simplification to write it on a single line, but your previous code with a test may be better. We may also want to test that the containsNick property hasn't been set before by the protocol specific code. Not sure if that's useful. That would give us something like: if (!("containsNick" in aProperties) && aText.indexOf(this.nick) != -1) aProperties.containsNick = true; >+ >+ // Skips everything above you (if the prototype chain was extended) >+ let proto = this; >+ while (proto.writeMessage != convChatWriteMessage) >+ proto = proto.__proto__; >+ >+ // Skips yourself (if an extension of the prototype chain did not supply >+ // writeMessage) >+ while (proto.writeMessage == convChatWriteMessage) >+ proto = proto.__proto__; >+ >+ // proto is one past you on the prototype chain, so call writeMessage >+ proto.writeMessage.call(this, aWho, aText, aProperties); Mook helped you to produce a beautifully generic code, but we don't really need that genericity here as you know the name of the prototype. I think this would work: GenericConversationPrototype.writeMessage.apply(this, arguments);

*** Original post on bio 661 as attmnt 498 at 2011-01-24 10:45:00 UTC *** (In reply to comment #2) > I would need some guidance to edit the interface. Here's a proposed patch for the idl and C++ changes needed.

*** Original post on bio 661 as attmnt 499 at 2011-01-24 15:23:00 UTC *** You pretty much wrote this whole patch now at this point flo, feel free to change the assignee or anything if you wanted. I decided to use call instead of apply just to make it cleaner, but I guess it doesn't really matter either way -- although I'm not sure if we should be making a new variable inside the method instead of directly adding to aProperties.

Comment on attachment 8352240 [details] [diff] [review] jsProtoHelper Patch v2.0 *** Original change on bio 661 attmnt 497 at 2011-01-24 15:23:54 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment on attachment 8352242 [details] [diff] [review] jsProtoHelper Patch v3.0 *** Original change on bio 661 attmnt 499 at 2011-01-24 19:49:07 UTC *** We rewrote this again together on IRC.

*** Original post on bio 661 at 2011-01-24 19:50:47 UTC *** We (clokep and myself) worked on this together on IRC, and I finally pushed https://hg.instantbird.org/instantbird/rev/82123845bacf which should fix the bug.

*** Original post on bio 661 at 2011-01-27 19:22:22 UTC *** Fixed and working in IRC-JavaScript.