#instantbird log on 11 17 2015

All times are UTC.

00:09:38 <-- PingWiN has quit (Ping timeout: 121 seconds)
00:11:43 --> Alex2 has joined #instantbird
00:24:49 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
00:32:43 <-- Bollebib has quit (Ping timeout: 121 seconds)
01:01:00 <-- aleth has quit (Quit: :tiuQ)
01:13:14 <-- arlolra has quit (Client exited)
01:23:44 --> clokep has joined #instantbird
01:23:45 * ChanServ sets mode +o clokep 
01:30:19 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
01:30:28 --> clokep has joined #instantbird
01:30:28 * ChanServ sets mode +o clokep 
01:35:15 <-- myk has quit (Ping timeout: 121 seconds)
02:21:05 --> rohandalvi has joined #instantbird
02:22:38 <-- rohandalvi has quit (Quit: )
02:54:43 <-- mikef has quit (*.net *.split)
02:54:43 <-- Fallen has quit (*.net *.split)
02:54:50 --> mikef has joined #instantbird
02:54:50 --> Fallen has joined #instantbird
03:37:12 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
04:47:08 <instant-buildbot> build #507 of linux64-nightly-default is complete: Failure [4failed compile]  Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/507
04:47:35 <instant-buildbot> build #1806 of win32-nightly-default is complete: Failure [4failed compile]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1806
04:59:30 <instant-buildbot> build #2974 of macosx-nightly-default is complete: Success [3build successful]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2974
06:05:38 <-- EionRobb has quit (Quit: Leaving.)
06:14:11 --> myk has joined #instantbird
06:38:19 * MattATobin is now known as Tobin 
06:59:09 --> EionRobb has joined #instantbird
07:38:00 --> mpmc has joined #instantbird
07:58:53 <-- myk has quit (Ping timeout: 121 seconds)
08:36:05 --> BWMerlin has joined #instantbird
09:26:13 <-- nhnt11 has quit (Ping timeout: 121 seconds)
09:41:47 --> nhnt11 has joined #instantbird
09:41:47 * ChanServ sets mode +h nhnt11 
09:48:08 --> Bollebib has joined #instantbird
09:52:30 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
10:00:20 <-- EionRobb has quit (Quit: Leaving.)
10:05:06 <-- Tonnes has quit (Connection closed)
10:09:59 <-- nhnt11 has quit (Ping timeout: 121 seconds)
10:13:56 <-- Alex2 has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
10:23:04 --> flo-retina has joined #instantbird
10:23:05 * ChanServ sets mode +qo flo-retina flo-retina 
10:37:52 --> nhnt11 has joined #instantbird
10:37:52 * ChanServ sets mode +h nhnt11 
10:45:57 <-- nhnt11 has quit (Ping timeout: 121 seconds)
10:46:46 --> nhnt11 has joined #instantbird
10:46:46 * ChanServ sets mode +h nhnt11 
10:50:12 --> freaktechnik_ has joined #instantbird
10:50:29 --> pWnnn has joined #instantbird
10:51:55 <-- freaktechnik has quit (Ping timeout: 121 seconds)
10:51:55 * freaktechnik_ is now known as freaktechnik 
10:52:54 <-- nhnt11 has quit (Ping timeout: 121 seconds)
11:25:03 --> clokep has joined #instantbird
11:25:03 * ChanServ sets mode +o clokep 
11:27:03 <freaktechnik> yay, ircHandlers.unregisterHandler doesn't unregister it. Weird.
11:27:26 <freaktechnik> oh, I see why
11:27:27 <freaktechnik> <_<
11:27:29 <freaktechnik> >_>
11:28:04 <freaktechnik> so to unregister, one is expected to do |ircHandlers._ircHandlers = ircHandlers.unregisterHandler(aHandler)|
11:28:32 <freaktechnik> clokep is that intended?
11:28:51 --> clokep_ has joined #instantbird
11:28:51 * ChanServ sets mode +o clokep_ 
11:30:45 <freaktechnik> wait, no
11:30:46 <freaktechnik> wut
11:30:49 <freaktechnik> I is confused
11:31:50 <-- clokep has quit (Ping timeout: 121 seconds)
11:32:08 --> clokep has joined #instantbird
11:32:08 * ChanServ sets mode +o clokep 
11:32:35 <freaktechnik> huh, so all I know is that unregisterHandler doesn't work, as in the array is unmodified. But I don't see why. Aren't arrays passed by reference?
11:32:54 <-- clokep_ has quit (Ping timeout: 121 seconds)
11:34:33 <clokep> freaktechnik: That is not the intention.
11:35:11 <freaktechnik> clokep: all I have observed so far, is that the handlers array is unmodified after calling unregister...
11:35:42 <freaktechnik> so I assume the _unregisterHandler change to aArray doesn't affect the actual array. But that's not how I remember JS working...
11:36:01 <clokep> That is how it should work, yeah.
11:40:45 <clokep> Unless someone is making a copy of the Array somewhere.
11:41:50 <freaktechnik> all I can say, is that doing |irchHandlers._ircHandlers = ircHandlers._ircHandlers.filter((h) => h.name != handlers.name)| works as you'd expect.
11:42:31 <clokep> Hmm....maybe filter doesn't modify the array and returns a new one
11:42:37 <freaktechnik> it does
11:42:52 <clokep> Well that's going to be the problem...
11:43:03 <freaktechnik> but _unregisterHandler does |aArray = aArray.filter((h) => h.name != aHandler.name)|
11:43:22 <freaktechnik> oh, wait, I understand now
11:43:29 <freaktechnik> I think
11:43:30 <clokep> Yeah that just reassigns the variable.
11:43:34 <freaktechnik> yup
11:43:39 <clokep> https://mxr.mozilla.org/comm-central/source/chat/protocols/irc/ircHandlers.jsm#66 should be the line you gave.
11:43:41 <freaktechnik> I'll qnew and fix it...
11:43:45 <clokep> (And all the similar lines)
11:43:58 <freaktechnik> https://mxr.mozilla.org/comm-central/source/chat/protocols/irc/ircHandlers.jsm#59
11:44:02 <clokep> Also...I hav eno idea why those *return* something.
11:44:04 <freaktechnik> should return
11:44:16 <freaktechnik> because register returns true or false depending on success
11:44:24 <clokep> Ah.
11:44:38 <clokep> Yes, that method should return so the callers can assign it back to this._<something>
11:45:04 <freaktechnik> also, is it by design that you can register multiple handlers with the same name?
11:45:12 <freaktechnik> so you can have multiple prios under the same name?
11:47:47 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
11:47:49 --> clokep has joined #instantbird
11:47:50 * ChanServ sets mode +o clokep 
11:48:41 --> clokep_ has joined #instantbird
11:48:41 * ChanServ sets mode +o clokep_ 
11:48:54 <clokep_> freaktechnik: The name is just ther eto help you debug.
11:49:09 <freaktechnik> and to unregister
11:49:25 <freaktechnik> unregistering goes by name
11:49:34 <freaktechnik> because that's the only identifier there is...
11:49:58 <clokep_> It's probably the intention that it's unique, yes.
11:50:14 <clokep_> That code would probably be simpler w/ a Map, which didn't exist when I wrote it. :P
11:50:20 --> aleth has joined #instantbird
11:50:20 * ChanServ sets mode +o aleth 
11:50:41 <freaktechnik> I'm asking this, because I'm currently registering some of the base IRC handlers which I then just leak
11:50:51 <freaktechnik> because unregistering would break other IRC accounts...
11:51:53 <-- clokep has quit (Ping timeout: 121 seconds)
11:51:53 * clokep_ is now known as clokep 
11:56:03 <instantbot> New Chat Core - IRC bug 1225454 filed by martin@humanoids.be.
11:56:04 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1225454 tri, --, ---, nobody, UNCO, Unregistering IRC handlers doesn't work
11:56:48 <clokep> Why are you registering them twice?
11:56:59 <clokep> So...that probably has unintended consequences.
11:57:06 <freaktechnik> the second time happens by instantbird
11:57:26 <freaktechnik> and yes it has, if my handlers get sorted before the builtin ones and the extension gets unloaded.
11:57:55 <clokep> Some of the built-in handlers do stuff and then return False to fall through to other handlers.
11:58:01 <freaktechnik> yes
11:58:02 <clokep> This could cause a handler to do something twice.
11:58:12 <clokep> So registering the same handler multiple times is a Bad Idea.
11:58:13 <freaktechnik> the problem is, the built in handlers aren't registered if there's no IRC account
12:00:30 <clokep> They're registered when the first one is instantiated, I think.
12:01:10 <clokep> (And depending on the order of accounts being initialized sounds like a bad idea btw. :-D)
12:01:22 <freaktechnik> well, whenever the protocol is constructed
12:01:44 <freaktechnik> hm, I just realized unloading is no problem, because Arrays hold strong references, right?
12:02:03 <freaktechnik> hmm, though contexts sometimes get nuked for extensions :S
12:02:07 <clokep> So to be clear, you have a protocol which inherits from IRC but then adds additional extensions?
12:02:18 <clokep> So it uses the IRC handlers, but then registeres as a separate prpl?
12:04:26 * clokep was wondering how hard it would be to instantiate your own handlers object...
12:04:33 <clokep> But that's a singleton and totally not designed for that.
12:05:53 * aleth is a bit confused by this discussion
12:06:25 <aleth> If the list of handlers is shared too, won't that mess up IRC?
12:06:31 <freaktechnik> nope
12:06:36 <freaktechnik> isEnabled can check for the protocol
12:06:43 <clokep> I'll be back in an hour.
12:06:46 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
12:07:41 <freaktechnik> I guess what I could do is "clone" the base IRC handlers I need and rename them and add my isEnabled.
12:13:55 <freaktechnik> I think this'll work 
12:13:56 <freaktechnik> https://github.com/freaktechnik/twitch-provider/blob/master/lib/twitch/handlers.js#L225-L237
12:14:09 <freaktechnik> well, if anything gets executed twice it's my problem.
12:20:23 <aleth> do twitch chat participants have avatars?
12:23:10 <-- BWMerlin has quit (Client exited)
12:25:40 --> Tonnes has joined #instantbird
12:26:27 <freaktechnik> aleth: yes :)
12:26:42 <aleth> freaktechnik: have you added them to the tooltips yet? ;)
12:29:26 --> nhnt11 has joined #instantbird
12:29:26 * ChanServ sets mode +h nhnt11 
12:29:44 <freaktechnik> aleth: https://github.com/freaktechnik/twitch-provider/blob/master/lib/twitch/participant.js#L24 -> https://i.imgur.com/K1RpObj.png
12:29:59 <aleth> nice :-)
12:30:04 <freaktechnik> (and uh yes, that tooltip coloring is a GTK3 bug)
12:30:08 <aleth> Does it use the IRC AVATAR extension?
12:30:18 <freaktechnik> nope
12:30:23 <freaktechnik> REST APIU
12:30:29 <aleth> ah
12:31:04 <freaktechnik> the IRC tags only contain so much info
12:31:19 <freaktechnik> but they still contain more than I can currently display with instantbird (-> message colors and stuff)
12:31:23 <freaktechnik> but that's low prio atm
12:52:36 --> clokep_work has joined #instantbird
12:52:36 * ChanServ sets mode +o clokep_work 
12:53:26 <-- aleth has quit (Ping timeout: 121 seconds)
12:54:09 <freaktechnik> clokep_work: I've fixed it by "cloning" the IRC base and CAP handlers and only activating them for my prpl. So if something goes wrong it only affects my prpl.
12:57:11 --> aleth has joined #instantbird
12:57:11 * ChanServ sets mode +o aleth 
13:00:19 <-- Bollebib has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
13:00:27 <clokep_work> freaktechnik: That's one way to do it. ;)
13:02:24 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
13:09:54 --> Bollebib has joined #instantbird
14:07:31 <instantbot> New Chat Core - IRC bug 1225468 filed by florian@queze.net.
14:07:33 --> instantbot has joined #instantbird
14:07:33 topic changed by fripp.mozilla.org to "Ask about Instantbird (http://instantbird.com) here! :-) | Current version is Instantbird 1.5 | News: http://blog.instantbird.org | Nightlies: http://nightly.instantbird.im (for testing only) | IRC logs: http://log.bezut.info | Pastebin: http://pastebin.instantbird.org | Bugs: https://bugzilla.mozilla.org"
14:07:33 * ChanServ sets mode +v instantbot 
14:09:19 <-- aleth has quit (Ping timeout: 121 seconds)
14:12:02 <clokep_work> freaktechnik: Sorry you've hit so many edge-cases. :)
14:12:16 <freaktechnik> It's fun to hit the edge cases ;)
14:12:34 <freaktechnik> though the "add-on SDK not getting the background frame on startup" edge case will be not so fun to fix
14:14:51 <flo-retina> isn't the add-on SDK an edge case in itself?
14:18:32 <freaktechnik> these days, yes
14:29:34 <-- flo-retina has quit (Ping timeout: 121 seconds)
14:29:52 --> flo-retina has joined #instantbird
14:29:53 * ChanServ sets mode +qo flo-retina flo-retina 
14:30:28 <-- Morian has quit (Ping timeout: 121 seconds)
14:30:47 <-- redDragon has quit (Ping timeout: 121 seconds)
14:38:16 --> redDragon has joined #instantbird
14:44:44 --> Morian has joined #instantbird
14:55:10 --> myk has joined #instantbird
15:01:03 <-- Morian has quit (Ping timeout: 121 seconds)
15:01:04 --> Morian has joined #instantbird
15:18:00 --> aleth has joined #instantbird
15:18:00 * ChanServ sets mode +o aleth 
15:51:47 --> MikkCZ has joined #instantbird
15:56:45 <-- myk has quit (Ping timeout: 121 seconds)
17:05:40 <MikkCZ> Hi. I noticed the chat l10n folder is identical with Thunderbird chat folder, maybe also other single files are same in both products. If there is some list of them, it would make the translation easier but also help me to keep it up to date and terminologicaly unified with TB/FF. Wouldn't be possible to use the one from Thunderbird repository? Also are there any plans to add Instantbird for localization via Pontoon.Mozilla.org.
17:06:39 <aleth> MikkCZ: good question!
17:06:56 <flo-retina> I don't know pontoon.mozilla.org. I discussed with someone working on mozilla l10n whether it would be possible to have the im/ folder in the standard mozilla l10n repository. The answer was "probably yes" but it wasn't a definitive answer.
17:06:58 <aleth> IB l10n is definitely going to change for the next release (which is the first since the move to com-central)
17:08:37 <aleth> chat/ certainly shouldn't have to be localized twice
17:09:15 <MikkCZ> If the Instantbird l10n is moved into hg.mozilla.org, no problem with that if we do not loose anything. I've already make sure both IB and TB have the same chat files localization.
17:09:51 <flo-retina> taking the chat/ folder from the mozilla localization shouldn't be difficult (we already take toolkit/ etc... from there)
17:10:20 <flo-retina> ideally what would be really interesting is to stop having our own set of l10n repositories
17:11:08 <MikkCZ> Pontoon is quite nice in the way it enables localization of every project Mozilla offers in one system (websites, AMO, products). If Instantbird l10n is moved to Mozilla repositories, there should be IMO no blocker for adding to Pontoon. Maybe it would be possible for the current state too.
17:11:44 <flo-retina> I haven't been able to spend much time on all the l10n stuff unfortunately
17:11:58 <flo-retina> until we get a full set of nightly builds, it's difficult to consider releasing.
17:12:05 <flo-retina> I'll focus on l10n when attempting to make beta builds.
17:12:34 <MikkCZ> Great. :)
17:38:51 --> Mnyromyr has joined #instantbird
17:50:45 --> arlolra has joined #instantbird
18:00:59 <-- MikkCZ has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
18:10:19 <-- Mnyromyr has quit (Ping timeout: 121 seconds)
18:10:41 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
18:11:30 --> Mnyromyr has joined #instantbird
18:24:51 <-- Mnyromyr has quit (Ping timeout: 121 seconds)
18:25:53 --> Mnyromyr has joined #instantbird
18:40:13 --> myk has joined #instantbird
19:13:11 <-- myk has quit (Ping timeout: 121 seconds)
19:15:21 --> myk has joined #instantbird
19:19:30 <clokep_work> aleth: http://mxr.mozilla.org/comm-central/source/chat/protocols/irc/ircBase.jsm#197
19:19:41 <clokep_work> Looks like we find ourself in the JOIN list.
19:35:02 --> mpmc has joined #instantbird
19:47:44 --> EionRobb has joined #instantbird
20:26:42 --> flo-retina has joined #instantbird
20:26:43 * ChanServ sets mode +qo flo-retina flo-retina 
21:08:28 --> satdav has joined #instantbird
21:09:10 <instantbot> aleth@instantbird.org changed the Resolution on bug 1089809 from --- to FIXED.
21:09:11 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1089809 nor, --, Instantbird 45, aleth, RESO FIXED, Unhandled IRC message 379
21:09:20 <instantbot> aleth@instantbird.org changed the Resolution on bug 1225454 from --- to FIXED.
21:09:21 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1225454 tri, --, Instantbird 45, martin, RESO FIXED, Unregistering IRC handlers doesn't work
21:11:22 <clokep_work> aleth: Thanks!
21:18:23 <-- myk has quit (Ping timeout: 121 seconds)
22:20:24 <freaktechnik> is there a way to make the user highlighting case-insensitive? As in, the colored usernames in instantbird.
22:20:34 <freaktechnik> (in messages)
22:22:01 <-- clokep_work has quit (Ping timeout: 121 seconds)
22:24:46 <-- Tobin has left #instantbird ("Our job is to state the truth and let the facts attend to themselves.")
22:33:25 --> myk has joined #instantbird
22:34:28 --> abdelrhman has joined #instantbird
22:39:03 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
22:43:21 <-- abdelrhman has quit (Ping timeout: 121 seconds)
22:45:56 --> abdelrhman has joined #instantbird
22:46:39 <aleth> freaktechnik: if you override/modify the regex in conversation.xml
22:47:17 <abdelrhman> sukhe: Hi :-)
22:47:23 <-- Mnyromyr has quit (Connection closed)
22:50:27 <freaktechnik> aleth: so not really. Okay.
22:56:03 <aleth> it's probably not case insensitive to avoid false positives from short nicks
22:56:56 <aleth> freaktechnik: you could normalize the capitalization in the prpl though if you were confident of it
22:57:18 <aleth> i.e. display a version of the message with the correct capitalization
22:57:57 <EionRobb> do you not have a normalization function for usernames like the one in libpurple?
22:58:00 <freaktechnik> I couldn't figure out a way to have normalized buddies with capitalization in the displayed nicknames.
22:58:39 <aleth> EionRobb: sure, this is kind of the inverse problem though
22:58:55 <freaktechnik> so I currently have a messy getParticipant method, which replaces the normalized irc version of the nickname if I get proper capitalization
22:59:18 <EionRobb> oic, passing one username for the theme and one for display
22:59:58 <freaktechnik> well, no, I actually want the highlights to be totally insensitive, but having normalized nicks in the backend vs. display names would be nice, too.
23:00:05 <aleth> freaktechnik: the irc prpl stores known capitalizations in the whoisInfo
23:00:12 <freaktechnik> but that's a different problem...
23:00:25 <freaktechnik> aleth: oh?
23:00:49 <aleth> and the nicks in the participant list use the capitalization from the server
23:01:18 <freaktechnik> yeah, problem is that the server doesn't use the correct capitalization but instead has the correct capitalization in an IRC tag.
23:01:42 <aleth> lol
23:01:53 <freaktechnik> yeah, it's fun
23:02:57 <aleth> if you can get the tag at the point where the participant object is created, that should make it work
23:03:12 <freaktechnik> but the proprietary version of the chat ignores capitalization for highlights, so that's why I want to do that too
23:03:48 <freaktechnik> aleth: I have capitalization working in the UI, there are a few other quirks, like only PRIVMSGs having the tag but not JOINs etc.
23:04:20 <aleth> yeah, so the only way I can see to do that would be to display fReaKTECHNik occurrences in messages as freaktechnic ;)
23:04:44 <aleth> (so the conversation.xml regex picks it up)
23:04:48 <freaktechnik> you mean normalizing highlights myself?
23:04:51 <freaktechnik> interesting idea.
23:04:51 <aleth> right
23:05:05 <aleth> using the displayMessage mechanism
23:05:20 <freaktechnik> another regexp in there can't hurt
23:05:24 <-- satdav has quit (Quit: Leaving)
23:05:49 <aleth> you'd have to be careful about false positives 
23:05:53 <EionRobb> oh, "highlights" as in a message arrived for oneself and it's displayed differently?
23:06:30 <freaktechnik> EionRobb: instantbird uses a color hashing on usernames and then colors all occurences of the username in that color
23:06:57 <EionRobb> ok yeah, that's what I thought you were talking about originially
23:07:13 <sukhe> abdelrhman: hi. I was here but now I am about to step out, sorry. can we talk later? sorry
23:08:45 <abdelrhman> OK, no problem
23:09:23 <sukhe> abdelrhman: please ping me the next time you come online. if it helps, I am in UTC -5
23:09:51 <abdelrhman> OK
23:10:26 <freaktechnik> aleth: the pattern for replacement would be along the lines of /(?:^|\s)username(?=\s|$)/gi which should give no false-positives.
23:11:04 <freaktechnik> I'd actually have to remember that first () to readd it when replacing.
23:11:06 <EionRobb> assuming the protocol has case-insenstive normalising of usernames
23:11:43 <freaktechnik> EionRobb: I'd replace that with the case-sensitive version of the username, so the highlight gets shown, yup
23:12:54 <-- myk has quit (Ping timeout: 121 seconds)
23:14:25 <freaktechnik> hm, though I'm not sure I'd want to do this on a room with over 100 people...
23:27:15 <abdelrhman> aleth: Is there another protocol that supports in-band registration? as I think we can make registration dialog generic.
23:29:05 <aleth> abdelrhman: not at the moment, though one could consider adding it (e.g. for IRC - register with nickserv)
23:29:22 <aleth> the problem to consider is what happens if the registration fails
23:29:24 <EionRobb> mxit
23:34:27 --> EionRobb1 has joined #instantbird
23:35:47 <abdelrhman> I think these kind of problems should be covered in XEPs
23:36:48 <-- EionRobb has quit (Ping timeout: 121 seconds)
23:37:34 <aleth> I'm sure they are. But how do you handle it in the UI?
23:37:41 <aleth> Something to think about ;)
23:43:29 <abdelrhman> Yeah, I got what you mean :)
23:53:29 --> clokep has joined #instantbird
23:53:29 * ChanServ sets mode +o clokep 
23:54:13 --> myk has joined #instantbird
23:57:58 <-- pWnnn has quit (Ping timeout: 121 seconds)