#instantbird log on 08 24 2013

All times are UTC.

00:01:11 <-- chrisccoulson has quit (Ping timeout)
00:02:06 <qheaden> Well, I'm going to stop right here for tonight. I'm trying to regulate my sleep schedule. ;)
00:02:33 <qheaden> Good night everyone.
00:04:44 <flo-retina> isn't it 8pm?
00:10:26 <flo-retina> Good night
00:13:49 <nhnt11> Good night qheaden, flo-retina
00:22:17 <instant-buildbot> build #457 of linux-onCommit is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/linux-onCommit/builds/457
00:23:41 --> clokep has joined #instantbird
00:23:41 * ChanServ sets mode +o clokep 
00:28:37 <clokep> flo-retina: My steps to reproduce are "attempt to log on" ;)
00:35:48 <instantbot> clokep@gmail.com set the Resolution field on bug 2123 to FIXED.
00:35:50 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2123 tri, --, 1.5, florian, RESO FIXED, 'Unhandled CAP/ISUPPORT messages' warnings are too noisy
00:36:38 <instantbot> clokep@gmail.com set the Resolution field on bug 2104 to FIXED.
00:36:44 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2104 nor, --, 1.5, nhnt11, RESO FIXED, Filenames for buddy icons are not null-checked in the new conversation tab.
00:37:29 <instantbot> clokep@gmail.com set the Resolution field on bug 1676 to FIXED.
00:37:31 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1676 tri, --, 1.5, aleth, RESO FIXED, 'function does not always return a value' warnings from moz14
00:44:22 <-- Mook_as has quit (Quit: Mook_as)
00:46:21 --> EionRobb has joined #instantbird
00:46:32 <-- Even has quit (Input/output error)
00:49:28 --> mconley has joined #instantbird
00:56:08 <-- dew has quit (Ping timeout)
00:56:12 --> dew has joined #instantbird
01:24:05 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
02:00:17 --> Mook has joined #instantbird
02:15:54 <-- EionRobb has quit (Connection reset by peer)
02:23:20 --> nhnt11 has joined #instantbird
02:31:57 <-- douglaswth has quit (Ping timeout)
02:33:04 --> douglaswth has joined #instantbird
02:44:09 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
03:05:44 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
03:38:43 <instant-buildbot> build #949 of macosx-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/949
03:51:31 <-- douglaswth has quit (Ping timeout)
03:51:58 --> douglaswth has joined #instantbird
03:57:24 <-- mconley has quit (Input/output error)
04:20:10 --> EionRobb has joined #instantbird
04:57:54 --> mconley has joined #instantbird
05:03:47 <-- mconley has quit (Ping timeout)
05:23:44 --> YH has joined #instantbird
05:27:38 --> mconley has joined #instantbird
05:37:39 --> nhnt11 has joined #instantbird
05:43:50 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
05:43:58 --> nhnt11 has joined #instantbird
05:58:11 <-- Mook has quit (Quit: Mook)
06:08:01 --> nhnt11-testing has joined #instantbird
06:11:40 <-- nhnt11-testing has quit (Client exited)
06:22:26 <-- YH has quit (Connection reset by peer)
06:22:32 --> YH has joined #instantbird
06:24:02 <nhnt11> C++
06:24:18 <nhnt11> Nothing, instantbot? :(
06:42:55 <-- nhnt11 has quit (Input/output error)
06:43:40 --> nhnt11 has joined #instantbird
06:45:20 <-- nhnt11 has quit (Ping timeout)
06:46:20 --> nhnt11 has joined #instantbird
06:48:00 <-- nhnt11 has quit (Ping timeout)
06:49:00 --> nhnt11 has joined #instantbird
06:50:03 <-- YH has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com)
07:02:50 <EionRobb> c++
07:32:48 <-- nhnt11 has quit (Input/output error)
07:37:49 --> YH has joined #instantbird
07:43:55 --> jb has joined #instantbird
07:55:45 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
07:55:50 --> flo-retina has joined #instantbird
07:55:50 * ChanServ sets mode +qo flo-retina flo-retina 
07:56:15 * flo-retina is so excited to have a new nightly that he doesn't even remember what to expect from it :)
07:56:33 <-- mconley has quit (Input/output error)
08:15:49 --> qlum has joined #instantbird
08:38:49 <-- jb has quit (Ping timeout)
09:05:53 --> nhnt11 has joined #instantbird
09:12:40 <-- EionRobb has quit (Ping timeout)
09:13:17 --> EionRobb has joined #instantbird
09:28:12 <-- nhnt11 has quit (Input/output error)
09:28:56 --> nhnt11 has joined #instantbird
09:31:19 --> jb has joined #instantbird
09:41:08 <-- nhnt11 has quit (Input/output error)
09:47:07 --> aleth has joined #instantbird
09:47:07 * ChanServ sets mode +h aleth 
10:06:05 <flo-retina> aleth: why is the ERROR response received from the server (that we expect!) causing an error to be sent to the account manager?
10:06:39 <-- jb has quit (Ping timeout)
10:09:31 <-- YH has quit (Ping timeout)
10:12:07 --> YH has joined #instantbird
10:18:56 <aleth> flo-retina: You mean, in the present code?
10:19:28 <flo-retina> aleth: I mean an account shouldn't auto reconnect after being disconnected with an OK code
10:19:41 <flo-retina> and we shouldn't send an error code after sending OK
10:19:49 <aleth> The server sends ERROR, we disconnect, we immediately start reconnecting, and then the server cuts the connection, causing the error in the bug.
10:20:29 <flo-retina> haven't we marked the account as disconnected before the ERROR?
10:21:36 <aleth> Yes, but http://lxr.instantbird.org/instantbird/source/chat/components/src/imAccounts.js#271
10:22:35 <flo-retina> yes. But that should reconnect the account the next time the user's status changes.
10:22:54 <flo-retina> oh wait
10:24:00 <flo-retina> Ok :-|
10:24:13 <aleth> It's IRC being different as usual ;)
10:24:30 <flo-retina> I still suspect there's a bug on the IRC side
10:24:41 <aleth> I couldn't find one
10:24:46 <flo-retina> if we disconnected the account ourselves
10:25:02 <flo-retina> we shouldn't care about any garbage received on that socket.
10:25:14 <flo-retina> so I don't see why the ERROR from the server affects our reconnection attempt.
10:25:32 <aleth> It doesn't, it's before the reconnection attempt
10:26:01 <flo-retina> well, if it's after the reportDisconnecting call, it shouldn't affect the error code.
10:26:15 <aleth> It doesn't affect the error code
10:26:51 <aleth> This is what changes the error code http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#703
10:27:13 <aleth> And the only reason that code is executed is because at that point the account is already reconnecting
10:27:22 <flo-retina> !this._account.imAccount why is this touching imAccount? :-S
10:27:34 <aleth> I have no idea
10:27:46 <flo-retina> can't this._account just become null if we don't care about what the server wants to send us any more?
10:28:23 <flo-retina> that's a separate ircSocket object
10:28:38 <flo-retina> when disconnecting the account, I would think we should cut any reference to it, and any reference from it to the account
10:29:03 <aleth> That account is in the .connecting state at that point
10:29:08 <aleth> it can't be null
10:29:19 <flo-retina> aleth: it's in the connecting state for a difference socket
10:29:29 <flo-retina> the old socket is just messing things up
10:29:34 <aleth> Hmm, could be
10:30:25 <flo-retina> http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#1461
10:31:16 <flo-retina> this._socket.disconnect() should likely drop the reference to this._account that the socket holds
10:31:36 <flo-retina> that may force us to add several null checks, but I think that would be safer
10:31:50 <flo-retina> if the account has dropped the reference to the socket, the socket shouldn't reference the account
10:33:24 <aleth> That makes sense.
10:33:39 <flo-retina> and I think this test http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#698 is really "strange"
10:34:09 <flo-retina> and broken, really
10:35:10 <aleth> Hmm, if we drop the reference to the account early, we also potentially \lose debug logging.
10:35:48 <flo-retina> what do we want to log?
10:36:16 <aleth> After disconnection, the socket object should cease to exist altogether
10:36:44 <aleth> Setting _account to null seems to be working around that, why would it be needed?
10:36:44 <flo-retina> don't we drop debug logs after a clean user-initiated disconnection?
10:37:10 <flo-retina> I remember being annoyed that IRC logs stuff to the debug log just after it's been emptied, and that looks like there was an ERROR at the beginning of the next connection attempt
10:37:25 <aleth> Yes, this happens.
10:37:45 <flo-retina> so we are probably happy to not have logs
10:38:07 <aleth> I'd rather see what is sent and received than make guesses about what to drop
10:38:11 <flo-retina> I wonder how many null checks we would need
10:38:27 <flo-retina> is onConnectionClosed the only method likely to be called after disconnect()?
10:38:39 <aleth> I think so.
10:39:47 <aleth> I would need to add dumps to be certain though as the IRC disconnect procedure is quite involved.
10:40:49 <flo-retina> after disconnecting an account cleanly and from the user's action, I expect a debug log to be empty.
10:40:57 <flo-retina> For an IRC (freenode) account, I have: http://pastebin.instantbird.com/303598
10:41:10 <flo-retina> do you think this is a good behavior? (I personally really dislike it)
10:41:38 <aleth> It's not pretty, but it's an artifact of when we flush the log, isn't it?
10:41:56 <flo-retina> we shouldn't log stuff after calling reportDisconnect
10:42:07 <flo-retina> between reportDisconnecting and reportDisconnected, it's OK
10:42:27 <flo-retina> "we shouldn't log stuff after calling reportDisconnect"*ed*
10:44:04 <aleth> I'm actually confused about how that's being logged now,
10:44:38 <flo-retina> the second one is from the socket
10:45:05 <flo-retina> the first one is a bit unfortunate, it's logged by the caller of reportDisconnected, but after calling reportDisconnected :-/
10:45:25 <aleth> Ah right
10:45:26 <flo-retina> and it's done after the call, because we want to log a different message (a warning) if the message couldn't be handled
10:45:30 <aleth> The handler does the logging
10:46:04 <flo-retina> it's http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/ircHandlers.jsm#104
10:46:38 <aleth> It seems overkill to put a disconnected check there.
10:46:46 <flo-retina> could we move line 104 to line 100?
10:47:04 <flo-retina> that would log unhandled messages twice, but is it really a problem?
10:47:12 <flo-retina> there aren't that many unhandled messages anyway
10:47:39 <flo-retina> s/100/95/
10:47:44 <aleth> Seems more likely to cause confusion than the existing behaviour though
10:47:56 <flo-retina> aleth: the current behavior confuses me ;)
10:48:54 <flo-retina> oh wait, the other message I was talking about is: http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#684
10:56:50 <aleth> What, now there are mac nightlies but no linux and win? :D
10:59:23 <aleth> Thanks for taking care of the mutationobserver warnings :)
11:02:01 <flo-retina> how did you guess what I was working on?
11:02:07 <flo-retina> (I'm looking at the one in blist.js right now)
11:02:18 <aleth> I was just looking at yesterday's logs
11:02:18 <flo-retina> errr, what?
11:02:30 <flo-retina> yeah, I guessed that :)
11:02:42 <flo-retina> was just kidding, as I'm actually working on these warnings right now :)
11:02:48 <aleth> :)
11:04:55 * flo-retina emailed Even to know what's up with his machine
11:06:08 --> florian has joined #instantbird
11:09:52 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
11:10:16 --> florian has joined #instantbird
11:10:31 <-- YH has quit (Ping timeout)
11:17:39 --> jb has joined #instantbird
11:35:40 <aleth> flo-retina: How about moving the emptying of the debug log from account-disconnected to account-connecting? That would get rid of those additional log message
11:38:20 <-- jb has quit (Ping timeout)
11:38:59 <aleth> It would also have the advantage that in the disconnected state one could still get the debug log of the previous session.
11:56:23 --> jb has joined #instantbird
12:07:57 <instantbot> New Core - General bug 2124 filed by aleth@instantbird.org.
12:07:58 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2775 on bug 2124.
12:07:59 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2124 nor, --, ---, aleth, ASSI, Retain debug logs until next connection attempt
12:13:04 <-- jb has quit (Ping timeout)
12:28:25 --> YH has joined #instantbird
12:33:46 --> clokep has joined #instantbird
12:33:46 * ChanServ sets mode +o clokep 
12:35:33 <clokep> So before you guys rewrite all of the socket code for IRC...
12:35:44 <clokep> Have we thought about reusing the same socket object? Would that help?
12:37:15 <clokep> I also really don't follow what you're trying to "fix" in the logging.
12:37:16 <aleth> I'm not convinced there need to be any changes yet. The only reason this came up at all was due to a bug which has a working patch.
12:38:25 <-- YH has quit (Ping timeout)
12:45:00 <flo-retina> aleth: we empty these logs when an account is cleanly disconnected so that a disconnected account doesn't waste any memory
12:45:20 <flo-retina> emptying on account-connecting isn't more useful than not emptying at all.
12:45:36 <aleth> flo-retina: I get that, but there's been instances where that's been annoying
12:45:45 <flo-retina> example?
12:45:50 <aleth> It's useful because it makes debug logs more readable
12:46:04 <flo-retina> clokep: and reusing the same socket object wouldn't help.
12:46:27 <clokep> flo-retina: "help would" I still really don't get what you're trying to fix.
12:47:57 <aleth> flo-retina: When testing something, or noticing some oddness, and deciding "too late" one wants to look at the log. Or more recently when wanting to look at the debug logging of the quit process ;)
12:49:27 <aleth> For the memory aspect, I'd suggest a generous timeout (10 minutes or something)
12:49:37 <flo-retina> clokep: and I'm not talking about rewriting all the ircSocket code, but just about http://pastebin.instantbird.com/303719 (completely untested, but I figured code would be clearer than words)
12:50:21 <aleth> I don't like that last bit (moving this.DEBUG)
12:50:26 <clokep> Interesting.
12:50:50 <flo-retina> aleth: the part I dislike is the unInit method
12:51:19 <aleth> flo-retina: Override disconnect in ircSonnect instead?
12:51:20 <flo-retina> aleth: I think I would prefer overriding the disconnect method by one that deletes this._account after calling the prototype's disconnect method
12:51:48 <aleth> :)
12:52:07 <flo-retina> aleth: I'm not very far from suggesting that we get rid of that DEBUG call
12:52:33 <flo-retina> aleth: If I understand correctly, its purpose is to show how a message was parsed; so I think it would be better to log that at the end of the parsing code
12:53:17 <flo-retina> anyway, that was by no mean intended to be taken as a finished patch ready for review; just a way to explain what I was _actually_ taking about.
12:53:25 <aleth> Sure.
12:53:34 <flo-retina> *talking
12:53:59 <clokep> flo-retina: We used to have a debug when a message was received and then one when parsed but you asked us to remove it. :-D
12:54:17 <clokep> s/it/one/
12:54:18 <flo-retina> clokep: I think what I asked to remove was the duplication in the logs ;)
12:54:35 <clokep> Bah, no update. :(
12:54:54 <flo-retina> aleth: btw, what do you dislike about the way that pastebin moves the DEBUG call?
12:55:11 <flo-retina> (would be easier to find a debug place if we agree about what we expect from that call)
12:55:21 <flo-retina> s/debug/correct/
12:55:28 * flo-retina needs to debug his typing
12:56:09 <flo-retina> uh
12:56:23 <flo-retina> I've just received an email from someone asking help about one of my Firefox add-ons
12:56:27 <aleth> flo-retina: It is cleaner to see either DEBUG or WARN or ERROR rather than always debug and then possibly additional messages
12:56:36 <flo-retina> it finishes by "P.S: I've also messaged you in Facebook, but it'll go to "Others" inbox so I figured I should've emailed you instead."
12:56:51 <flo-retina> why would someone find the author of an add-on on Facebook to send a request for help there? :-S
12:57:10 <aleth> Some people use facebook for everything :-S
12:57:24 <flo-retina> aleth: well, I see it as the DEBUG call showing how we parsed the message, then the WARN/ERROR about how we failed to handle it. Those are really 2 different things.
12:58:06 <aleth> I'll defer to clokep on that one.
12:58:25 <flo-retina> on facebook I see one "<name> asked to join I love Instantbird." <-- why would we have to accept requests to join a group? :-S
13:00:07 <flo-retina> aleth: well, the DEBUG call move is arguably unrelated to the /quit bug you were trying to fix. Fixing the broken test at http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#698 is really part of that bug though. It's the cause for the strange error message in the account manager
13:02:21 <aleth> flo-retina: I don't mind including a fix for that part (though the issue no longer arises with the changes that are already in the patch)
13:03:04 <flo-retina> aleth: "though the issue no longer arises" no, it is hidden.
13:03:29 <flo-retina> or you could say it's a different issue if you want.
13:03:38 <aleth> Hidden by the if clause working the way clokep intended it to work ;)
13:03:49 <aleth> But I agree deleting this.account is cleaner.\
13:04:26 <flo-retina> But if you are disconnected from IRC for some obscure reason (like a timeout) and the account auto-reconnects, you may still have an error code sent by and old socket to an account in the process of reconnecting
13:05:08 <aleth> I thought that was intentional?
13:05:11 <flo-retina> aleth: the test at irc.js#698 doesn't work the way anybody intended it to work; it's just broken.
13:05:27 <flo-retina> how could that be?
13:05:46 <aleth> If you are disconnected for an obscure reason, shouldn't that disconnection be reported?
13:05:53 <flo-retina> that the error goes to the log may be intentional; that the reconnect attempt is cancelled... I don't see
13:07:40 <flo-retina> aleth: so the situation I have in mind that typically happens to me is:
13:07:40 <flo-retina> 1. I'm connected to IRC through an SSH tunnel. 2. My real (local) internet connection starts to suck. 3. The IRC account timeouts locally and wants to reconnect.
13:07:40 <flo-retina> 4. Once the internet connection works again, the SSH tunnel wasn't actually broken (they are very resistant :)) and I receive an ERROR from the server because I haven't replied to PINGs that were buffered on the other side of the SSH tunnel while my local internet connection was down.
13:07:44 <aleth> Usually when you are disconnected for an obscure reason, onConnectionClosed is the first anyone hears about it. That if clause is there for intentional disconnections.
13:08:41 <aleth> Maybe clokep can tell us how he expected that to work though ;)
13:09:17 <flo-retina> we may want that ERROR from the server to be logged (it doesn't have a lot of value, but it may have some), but we certainly don't want that ERROR coming on the socket of the previous connection to stop the current reconnection attempt.
13:09:24 <aleth> "The IRC account timeouts" would be onConnectionTimedOut
13:09:35 <flo-retina> and?
13:09:54 <clokep> aleth: That code wasn't entirely written be me.
13:10:12 <clokep> flo-retina and I (and probably you) have all touched that code a handful of times because it's never fully worked.
13:10:12 <flo-retina> yeah, it could be that I wrote those 3 crappy lines :-D
13:10:40 <clokep> Why I don't understand is why we're reconnecting before we receive an ERROR from the previous connection.
13:10:43 <clokep> That seems like a bug.
13:10:59 <flo-retina> clokep: because we stop expecting it after a while (1s?)
13:11:02 <aleth> clokep: We don't reconnect before receving the ERROR
13:11:10 <flo-retina> aleth: we do
13:11:20 <flo-retina> (in the ssh tunnel case I described)
13:11:37 <aleth> OK, not in the /quit case though
13:12:07 <clokep> flo-retina: After we "stop expecting it" shouldn't that socket immediately be killed and we get no more data on it?
13:13:45 <flo-retina> clokep: we kill the link from the account to the socket, but the socket keeps the link to the account and can still send us some stuff
13:13:53 <flo-retina> (until it's GC'ed I guess)
13:14:07 <clokep> WTF :-S
13:14:24 <flo-retina> clokep: that's what the unInit method in my pastebin fixes
13:14:27 <clokep> If we replace it with another object I'd expect it to just "go away" that makes no sense to me.
13:14:45 <clokep> Then yes, I'd agree that's what needs to get done.
13:14:49 <flo-retina> where "go away" means "be garbage collected at some point"
13:14:59 <flo-retina> that could happen several seconds later
13:15:05 <aleth> Ah, that's a good point that gc is not instant
13:15:07 <clokep> Yes, but I'd expect it to be "inactive" or whatever, but this gets into my lack of a CS background. ;)
13:15:28 <clokep> I disagree with aleth that we want to log messages on that connection anymore, by the way.
13:15:34 <clokep> We DO NOT CARE about that socket connection anymore.
13:15:40 <clokep> To us, those messages were never received.
13:15:42 <flo-retina> clokep: well, it's possible my explanation is a bit confusing because we still miss some part of the explanation about what's actually going on
13:15:58 <flo-retina> but the link between an old socket and an account that may have changed status really seems awfully wrong to me ;)
13:16:14 <aleth> clokep: The messages we are talking about is a single one, the ERROR reply which we do care about. The issue is we call this.DEBUG after reportDisconnected
13:16:33 <clokep> aleth: No, we don't care abou tERROR, unless it's called before the one second timeout.
13:16:41 <aleth> It is.
13:16:49 <clokep> Then I still don't understand.
13:16:51 <flo-retina> not always :)
13:16:59 <aleth> flo cares about it cluttering up the debug log of the next session ;)
13:17:22 <flo-retina> aleth: wait.
13:17:25 <clokep> If it is received before the 1s timeout it shouldn't be part of the next session unless something is screwed up in the logging code.
13:18:02 <flo-retina> aleth: the message I get rid of by killing the link between the socket and the account with the pastebined patch is the "onStopRequest" one, not the ERROR one (this one I get rid by moving the DEBUG call up in the handleMessage method)
13:18:19 <aleth> flo-retina: Sure, I get that. I'm talking about the latter
13:18:34 <flo-retina> aleth: I said the later could arguably be a different bug.
13:19:06 <aleth> flo-retina: I agree, and my proposed solution was to flush the logs 10 minutes later.
13:19:38 <aleth> (as you didn't like on the next connection due to memory concerns)
13:20:28 <flo-retina> aleth: I see that proposal as a separate enhancement suggestion (and I'm not sure it really enhances anything (I would likely prefer observing the memory pressure notifications), but that's debatable), not a fix for the bug.
13:21:09 <aleth> Depends on whether you consider calling this.DEBUG after reportDisconnected a bug or not ;)
13:21:20 <flo-retina> it is a bug from my point of view.
13:21:50 <aleth> OK
13:22:33 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
13:23:03 --> florian has joined #instantbird
13:23:26 <aleth> Then I don't see an alternative to moving this.DEBUG as you suggested
13:23:46 <flo-retina> it's annoying that the mutation observers cause assertions :( (##!!! ASSERTION: event for content that isn't in a document: 'doc', file /Users/florian/buildhg/hg.instantbird.org/mozilla/layout/base/nsPresShell.cpp, line 6603)
13:27:41 <instantbot> aleth@instantbird.org cancelled review?(clokep@gmail.com) for attachment 2768 on bug 1994.
13:27:46 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
13:28:45 <flo-retina> oh cool, that assertion was added in Mozilla 22 by a bug still marked as security critical :(
13:28:58 <aleth> :(
13:29:57 * flo-retina files a bug
13:38:45 <flo-retina> filed https://bugzilla.mozilla.org/show_bug.cgi?id=909006
13:41:29 <instantbot> florian@instantbird.org denied review for attachment 2775 on bug 2124.
13:41:31 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2124 nor, --, ---, aleth, ASSI, Retain debug logs until next connection attempt
13:46:54 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
13:56:20 --> YH has joined #instantbird
13:59:23 <flo-retina> the mutation observer added by bug 1626 is annoying (as I don't have a way to check that stuff still works after I convert it)
13:59:27 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1626 nor, --, 1.3, aleth, RESO FIXED, Some screen readers say the word "frame" a lot when moving the selection in the contacts list
14:00:23 <aleth> Probably the only solution is to ask for f?jamie on that one
14:00:58 --> jb has joined #instantbird
14:02:27 <flo-retina> I'll add the new code, keep the old one, and add a dump in both
14:02:38 <flo-retina> if the dumps are displayed next to each other, I'll assume my new code works OK
14:03:08 <-- jb has quit (Ping timeout)
14:03:10 <flo-retina> but I may add a comment in the accessibility bug so that if a regression is ever reported, we can find quickly where to look at
14:03:27 --> jb has joined #instantbird
14:03:43 <aleth> I was planning to f?jamie on the awesometab after bug 2066 lands anyway so we could mention it to him then
14:03:46 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2066 enh, --, ---, nhnt11, NEW, New conversation tab should suggest chat rooms
14:04:16 <flo-retina> good idea :)
14:05:02 <-- jb has quit (Input/output error)
14:06:12 --> jb has joined #instantbird
14:09:44 <instantbot> aleth@instantbird.org requested review from clokep@gmail.com for attachment 2776 on bug 1994.
14:09:47 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
14:10:05 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2776 on bug 1994.
14:10:16 <flo-retina> clokep, aleth: anybody knows what's going on in http://i4.minus.com/ibnHiabRmheG5.png ('this.WARN is not a function' exception in setMode in irc.js) I ignored it at first because I thought it was caused by the patch I pastebined... but I've just noticed after killing my debug build that this was actually the error console of my nightly :-S.
14:10:53 <clokep> I can guess what it is. ;)
14:10:57 <clokep> But I don't know for sure.
14:10:59 <flo-retina> (that kind of stuff was invisible when there was a lot of rubbish in my error console ;))
14:11:07 <flo-retina> clokep: I would guess the this value is wrong
14:11:14 * clokep is paying builds.
14:11:18 <clokep> bills
14:11:20 <clokep> Not builds. :(
14:11:24 <flo-retina> but I can't guess if this is a recent regression or not
14:11:44 <flo-retina> clokep: I still don't understand why that isn't automated, like companies do it with sites like bill.com... :(
14:12:07 <flo-retina> clokep: I would like to login to my bank's website monthly, and approve at once all the uninteresting bills (electricity, etc...)
14:12:32 <clokep> You can kind of do that.
14:12:41 <clokep> I dislike paying bills online, but that's a discussion for #chatdev. ;)
14:12:51 <clokep> flo-retina: I vaguely feel like we had this bug once before.
14:12:54 <clokep> And that we fixed it.
14:12:57 <clokep> But maybe it was just similar.
14:13:05 <aleth> flo-retina: No direct debits in France?
14:16:25 <aleth> Actually having made those ircSocket changes, I think the bug flo spotted there was also responsible for the occasional weird SSL error I saw on connecting to moznet
14:16:45 <-- jb has quit (Quit: jb)
14:18:04 <-- YH has quit (Ping timeout)
14:18:09 --> jb has joined #instantbird
14:18:44 <-- jb has quit (Input/output error)
14:19:53 --> jb has joined #instantbird
14:25:42 <-- qlum has quit (Client exited)
14:26:08 --> YH has joined #instantbird
14:34:07 <-- YH has quit (Connection reset by peer)
14:34:12 --> YH has joined #instantbird
14:38:30 <flo-retina> aleth: I think the SSL errors are due to session tickets
14:38:50 <flo-retina> ah, we may not be talking about the same ssl errors
14:39:03 <flo-retina> I remember then was another one I got less frequently; you may be talking about that one :)
14:39:12 <aleth> I'm talking about ones I only ever saw on frequent reconnects during debugging
14:42:12 --> Even has joined #instantbird
14:42:12 * ChanServ sets mode +o Even 
14:43:56 <-- jb has quit (Ping timeout)
14:57:28 <instantbot> florian@instantbird.org denied review for attachment 2776 on bug 1994.
14:57:30 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
14:58:37 <clokep> Ah, that means I don't need to review that, right? :)
14:58:45 <flo-retina> yes
14:58:58 <aleth> bah, this.
14:59:05 <aleth> Good catch
15:03:11 <-- YH has quit (Connection reset by peer)
15:03:18 --> YH has joined #instantbird
15:05:48 <flo-retina> clokep: btw, did I see correctly that you made your first checkin that's going to end up in mozilla-central this night? :)
15:06:03 <clokep> flo-retina: No. I've done it before.
15:06:36 <clokep> flo-retina: https://bugzilla.mozilla.org/show_bug.cgi?id=894367#c5
15:07:01 <flo-retina> ah :)
15:07:55 <flo-retina> is the checkin-needed for comm-central?
15:08:51 <flo-retina> clokep: btw, the nonce problem on jabber.org that you mentioned before today looks very similar to https://bugzilla.mozilla.org/show_bug.cgi?id=817596
15:09:08 <-- YH has quit (Ping timeout)
15:09:44 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2777 on bug 2009.
15:09:49 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2009 nor, --, ---, aleth, ASSI, Accounts don't automatically reconnect when back online if the "offline" status was set while the co
15:12:05 <clokep> flo-retina: Yes.
15:12:10 * clokep is hoping RyanVM does it.
15:12:38 <instantbot> florian@instantbird.org granted review for attachment 2777 on bug 2009.
15:12:40 <clokep> flo-retina: And yes, it does look very similar. :)
15:12:41 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2009 nor, --, ---, aleth, ASSI, Accounts don't automatically reconnect when back online if the "offline" status was set while the co
15:12:50 <flo-retina> clokep: I'm afraid checkin-needed + an m-i link may be slightly confusing
15:12:55 <flo-retina> but we'll see what happens :)
15:13:13 <clokep> It's metered check-in but no one was around to tell me it was OK so. :)
15:13:37 * flo-retina is glad to see his "instantbird sucks when arriving at the hotel in the evening" bug is getting fixed, but annoyed we've had so many fixes around account reconnection already
15:13:51 <flo-retina> that piece of code really looks like it would want unit tests
15:13:51 <-- instant-buildbot has quit (Connection reset by peer)
15:13:54 <aleth> Touching that code always makes me nervous.
15:14:04 <flo-retina> aleth: yeah, I'm afraid of touching it :(
15:14:32 --> instant-buildbot has joined #instantbird
15:14:33 * ChanServ sets mode +v instant-buildbot 
15:17:37 <instantbot> aleth@instantbird.org cancelled review?(clokep@gmail.com) for attachment 2776 on bug 1994.
15:17:38 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2778 on bug 1994.
15:17:40 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
15:17:51 <clokep> Does something need my review? I'm leaving in a few minutes.
15:18:12 <flo-retina> I'm hopefully going to attach more mutation observer stuff 'soon'
15:18:17 <instantbot> aleth@instantbird.org requested review from clokep@gmail.com for attachment 2778 on bug 1994.
15:18:29 <flo-retina> but I think it neither needs your review specifically, nor a quick review
15:20:46 <flo-retina> aleth: why is the _reportDisconnecting call no longer needed in disconnect: ?
15:21:14 <clokep> If I get bored I'll do it on my phone. ;)
15:21:29 <aleth> flo-retina: It was called twice, if you follow the code path
15:21:41 <flo-retina> I'm just looking at the patch right now :-]
15:22:30 <clokep> aleth: Can't we now do return handler.commands[aCommand]...?
15:23:21 <flo-retina> clokep: it's in a for each loop
15:23:49 <aleth> clokep: Yes, but I don't think that is as readable
15:23:56 <clokep> Ah, yes.
15:24:22 <clokep> I misread that, yes. :)
15:24:30 <clokep> The calling the commmand is part of the if-statement. ;)
15:24:40 <aleth> Yes
15:25:48 <clokep> aleth: I don't have time to look over that now, I'll do it later.
15:26:57 --> YH has joined #instantbird
15:32:12 <-- EionRobb has quit (Quit: Leaving.)
15:33:14 <instantbot> florian@instantbird.org granted review for attachment 2778 on bug 1994.
15:33:17 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
15:34:05 * flo-retina wonders if aleth is in the mood of finishing the account manager changes that we started when we were alraedy string frozen for a previous release
15:34:14 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
15:34:19 --> flo-retina has joined #instantbird
15:34:19 * ChanServ sets mode +qo flo-retina flo-retina 
15:35:28 <flo-retina> the stuff to have the second line say "Will be reconnected once the status is set to online." if the user clicks "connect" while in the offline status
15:35:36 <instantbot> clokep@gmail.com granted review for attachment 2778 on bug 1994.
15:35:39 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
15:35:40 <aleth> It's somewhere on the todo list...
15:35:56 <flo-retina> aleth: I'm sure it is
15:36:24 <aleth> There were a bunch of related changes to that UX that were wanted iirc
15:36:33 <flo-retina> I was just wondering if you've read enough of stuff about disconnecting/reconnecting accounts during the last few days to have enough of the mental context so that it's easier today :)
15:36:34 <clokep> My todo list hasn't had anything touched in a LONG time. :(
15:37:04 <flo-retina> todo list is the place where we put the stuff that'll never actually get done ;)
15:37:31 <aleth> True, but I'm out of time for today
15:37:48 <flo-retina> fair enough :)
15:38:00 * flo-retina hasn't made much progress on his mutation warnings killing
15:38:05 <aleth> Blame bug 1994...
15:38:09 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
15:38:20 <flo-retina> but has significantly improved his average review time :)
15:38:40 <flo-retina> aleth: yeah, I think we all hate that bug at this point ;)
15:39:07 <flo-retina> but if it actually cleans up the debug logs after a disconnection is finished, it may reduce my confusion later :)
15:40:12 <-- instant-buildbot has quit (Connection reset by peer)
15:40:22 <flo-retina> http://i5.minus.com/ig4hR57Tr11rd.png :-S
15:40:26 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2779 on bug 1994.
15:40:28 <aleth> It does clean things up a bit ;)
15:40:29 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
15:40:39 --> instant-buildbot has joined #instantbird
15:40:39 * ChanServ sets mode +v instant-buildbot 
15:40:54 <aleth> We should really investigate that strange SASL error. Did you file a bug?
15:41:02 <flo-retina> no
15:41:17 <flo-retina> but I'm pretty sure it's because I'm connecting with a nick that isn't the first one of the group
15:41:25 <aleth> Oh, that bug.
15:41:47 <clokep> I think we just don't gracefully handle the error in that situation, yes.
15:41:54 <aleth> We could finish atuljangras bonding period bug and then add group support...
15:42:00 <flo-retina> my screenshot was more to show the first 2 errors
15:42:06 <aleth> That would probably be the "right" thing to do.
15:42:14 <flo-retina> I would hope the second one wouldn't be visible after the patch for 1994
15:43:01 <clokep> aleth: You or I could finish that in ~15 minutes, I think.
15:43:09 <clokep> But I'm leaving now. :)
15:43:10 <clokep> Tta.
15:43:15 * flo-retina isn't sure what bug that is
15:43:32 <flo-retina> clokep: enjoy the afternoon :)
15:43:36 <aleth> The alternative nicks one. It wasn't a very hard bug...
15:43:46 <flo-retina> ah right
15:43:46 <aleth> clokep: Enjoy the country :)
15:43:48 <clokep> Which is why it was a good starter bug. :)
15:43:55 <clokep> I'll let you know if anything insane happens. ;)
15:43:55 <aleth> Right!
15:44:03 <flo-retina> we should still handle the error better
15:44:19 <flo-retina> ftr, my 'first' nick in the group is fqueze_ and I'm connecting with fqueze
15:44:47 * clokep isn't sure how we should really handle that btw...
15:45:30 <-- Even has quit (Input/output error)
15:45:49 <flo-retina> not sure either; but I'm sure we can display error messages or warnings that aren't just plain wrong :)
15:46:06 <instantbot> florian@instantbird.org granted review for attachment 2779 on bug 1994.
15:46:09 <flo-retina> :)
15:46:10 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1994 nor, --, ---, aleth, ASSI, Account reconnects after using the /quit command
15:46:27 <-- clokep has quit (Ping timeout)
15:46:30 <flo-retina> where ":)" means "finally!!!" ;)
15:47:25 <aleth> Yay :) IRC bugs do sometimes have that tendency to get a bit involved...
15:48:12 <flo-retina> it's also that when the code is messy, we need to understand something that was written by confused people; so it tends to quickly get confusing ;)
15:48:25 <aleth> Yup.
15:48:32 <aleth> You were right to insist on looking at the socket code again.
15:48:43 <flo-retina> obviously the parts that aren't messy are more straight forward to fix when a thing doesn't behave as expected
15:48:52 <flo-retina> aleth: thanks :)
15:49:21 <flo-retina> now if only we could fix that nickserv timer to not leak ;)
15:49:25 <aleth> The problem in IRC is to disentangle required messiness from other messiness ;)
15:49:39 <flo-retina> I'm still annoyed that I frequently see that leak on shutdown
15:49:50 <flo-retina> aleth: ahah, that's so true :)
15:50:32 <aleth> Btw would be great if bug 2066 and bug 451 were ready too...
15:50:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2066 enh, --, ---, nhnt11, NEW, New conversation tab should suggest chat rooms
15:50:37 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=451 nor, --, ---, aleth, NEW, Participants Need Context Menu
15:50:52 <flo-retina> how much work is left there?
15:51:00 <aleth> I think they are ready
15:51:17 <aleth> (with caveats that are better left for followups)
15:54:00 <flo-retina> it's difficult to believe that it took me almost the whole afternoon to fix 2 mutation observers
15:54:04 <flo-retina> and that was only one warning
15:54:13 <flo-retina> because apparently there's at most one warning per DOM window...
15:54:31 <flo-retina> so fixing the first one just changed the location reported by the warning instead of getting rid of it
15:54:37 <flo-retina> (that confused me a bit)
15:54:50 <flo-retina> but at least now, no more mutation warning when opening the buddy list :)
15:54:54 <aleth> That does sound confusing
15:55:11 <flo-retina> there's one when displaying a buddy tooltip though :(
15:55:13 <aleth> Well, mutation observers as a whole seem to complicate the code...
15:55:25 <flo-retina> yes, they definitely complicate the code
15:55:26 <aleth> Maybe not once one has understood them though ;)
15:55:28 <flo-retina> and it's hard to indent
15:55:35 <flo-retina> but the performance is likely much better
15:55:50 <aleth> For bubbles, that could be a big win
15:56:01 <flo-retina> for bubbles I would also like to port Mook's patch
15:56:02 <aleth> who knows...
15:56:08 <flo-retina> but I figured that would be better as a separate patch
15:56:16 <aleth> Definitely, when it's r+
15:56:36 <flo-retina> I think Mook's patch is ready for r+
15:56:47 <flo-retina> I need to look at it again, but last time I looked (I was tired) it looked good
15:58:35 * flo-retina is puzzled by http://lxr.instantbird.org/instantbird/source/instantbird/content/buddytooltip.xml#90
15:59:36 <aleth> That's weird. Couldn't an xbl:inherit do the same thing?
15:59:46 <flo-retina> no
16:00:00 <flo-retina> it's listening for changes of the status attribute on the contact or buddy or tab tag
16:00:18 <flo-retina> but what puzzles me is that it will then update only the status attribute (so the status icon) on the tooltip, but not the status message
16:00:22 <aleth> And the tooltip is not a child of those...
16:00:24 <flo-retina> I don't see how that could be the right thing to do
16:00:48 <aleth> Could be a bug that noone noticed?
16:01:05 <flo-retina> I would expect the code to just observe the imIBuddy for notifications...
16:01:13 <flo-retina> yeah... that code is old
16:02:24 <flo-retina> wait, the code actually has observers
16:03:32 * flo-retina is tempted to just remove that code and see if anybody gets upset
16:03:47 <aleth> Sounds good :)
16:04:49 <flo-retina> so the only case where we don't have observers is for conversations that don't have a buddy
16:04:58 <flo-retina> so MUCs or private conversations with people not in the list
16:05:08 <flo-retina> are there interesting changes of the "status" attribute for them?
16:05:21 <aleth> The status attribute is broken for the latter
16:05:36 <aleth> and doesn't exist for MUCs
16:05:47 <flo-retina> bah http://lxr.instantbird.org/instantbird/source/instantbird/content/buddytooltip.xml#334
16:05:47 <aleth> There would be topic changes I suppose
16:06:00 <flo-retina> aleth: and the left attribute
16:06:06 <aleth> AH yes
16:06:13 <flo-retina> but I suspect tooltips don't even handle that yet
16:06:23 <flo-retina> and that should be done by observing the conversation
16:06:30 <flo-retina> so I can still kill the mutation events
16:06:34 <aleth> Doing that by watching an attribute seems wrong
16:06:47 <flo-retina> we also do it for the all tabs menu
16:06:54 <flo-retina> but it seems more appropriate there
16:06:55 <aleth> Right, tooltips currently ignore .left
16:07:34 <flo-retina> yeah
16:07:43 <flo-retina> and I don't want to butcher tooltips until wnayes' patch lands
16:07:49 <aleth> wnayes might have changed that ')
16:08:05 <flo-retina> the mutation events?
16:08:09 <flo-retina> I don't think he touched that
16:08:23 <aleth> No, the fact they ignore left
16:08:52 <flo-retina> maybe, we can hope :)
16:09:03 <flo-retina> (or put that as a review comment :-D)
16:22:48 <-- YH has quit (Ping timeout)
16:27:25 --> YH has joined #instantbird
16:42:28 --> mconley has joined #instantbird
16:43:39 --> wnayes has joined #instantbird
17:20:15 --> Even has joined #instantbird
17:20:15 * ChanServ sets mode +o Even 
17:32:28 <flo-retina> It would be nice if my nexus 4 could stop resetting itself automatically to the pacific timezone...
17:38:24 --> florian has joined #instantbird
17:40:00 <aleth> That's unfortunate... Syncing to the wrong time server?
17:40:22 <flo-retina> just forgetting that I told it to use the cell tower's timezone
17:40:42 <flo-retina> bug I should have guessed something was wrong when the background image changed for no apparent reason :-S
17:47:42 <flo-retina> bah https://bugzilla.mozilla.org/show_bug.cgi?id=909006#c1 :(
17:50:37 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
17:51:05 --> florian has joined #instantbird
17:51:33 <aleth> always fun. did he realize the linked bug was protected?
17:51:49 <flo-retina> doesn't matter, I'm in the security group ;)
17:51:56 <aleth> ahaha :)
17:52:05 <flo-retina> no, the problem is that the test case is Instantbird ;)
17:52:12 <flo-retina> and on moz22
17:52:25 <flo-retina> I'll try later tonight if I find time to create a patch causing the assertion on Firefox
17:52:25 <aleth> Yeah, I got that part...
17:52:37 <flo-retina> an observer on the tab bar should do when a tab is removed
17:54:38 <flo-retina> aleth: btw, I didn't read the linked bug. Way too long.
17:54:43 <flo-retina> + I don't understand any of that code anyway
17:55:11 <flo-retina> I just saw it was a fix for a crash that was considered security critical
17:55:45 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
17:56:07 --> florian has joined #instantbird
17:56:21 <aleth> I was wondering more about possible "oh we fixed that for moz24" visible only from there
17:56:45 <flo-retina> the assertion is still in the file on mozilla-central
17:56:59 <flo-retina> and hidden bug has target milestone = moz22
17:57:11 <flo-retina> but was uplifted to a couple places (including esr17)
17:59:13 <flo-retina> FYI, there likely won't be Windows/Linux nightlies this night. Even hard trouble with a faulty hard disk in his RAID array, and decided to renew all the disks, so he's rebuilding the array (and copying a lot of data)
18:01:52 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
18:02:04 <aleth> Oh, bad luck
18:02:15 --> florian has joined #instantbird
18:03:07 --> FireFly_TB has joined #instantbird
18:04:20 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
18:04:44 --> florian has joined #instantbird
18:06:03 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
18:06:24 --> florian has joined #instantbird
18:08:18 <florian> alright, the 2 mutation observers in conversation.xml are fixed
18:12:04 <flo-retina> arg, there are actually 2 in tabbrowser.xml
18:13:26 <-- FireFly_TB has quit (Ping timeout)
18:18:38 <flo-retina> it's not even clear what http://lxr.instantbird.org/instantbird/source/instantbird/content/tabbrowser.xml#2143 is doing :-S
18:19:00 * aleth really dislikes code like that
18:19:43 <aleth> I think it means don't close the tab until you release the mouse button over the little X
18:20:32 <aleth> Oh wait, I was looking at the wrong line
18:20:32 --> FireFly_TB has joined #instantbird
18:23:42 <flo-retina> alright, I think I now understand what it does, and am ready to rewrite it
18:24:03 <-- YH has quit (Connection reset by peer)
18:24:08 --> YH has joined #instantbird
18:24:12 <flo-retina> hopefully it will be less obfuscated after the rewrite :)
18:24:40 * aleth loves comments like "// Tooltip was added. Stop using our tooltiptext attribute." ;)
18:24:42 --> Mook has joined #instantbird
18:39:03 <flo-retina> aleth: I won't change that comment :-P
18:39:41 <aleth> If anything, I would remove it ;)
18:40:03 <aleth> But maybe it's needed after your changes...
18:46:34 <-- aleth has quit (Quit: Ciao)
18:59:54 --> jb has joined #instantbird
19:25:07 <-- Mook has quit (Quit: Mook)
19:33:51 <-- YH has quit (Connection reset by peer)
19:35:42 <-- FireFly_TB has quit (Ping timeout)
19:37:47 <-- jb has quit (Ping timeout)
19:38:07 --> FireFly_TB has joined #instantbird
20:03:51 --> nhnt11 has joined #instantbird
20:05:53 --> rosonline has joined #instantbird
20:06:44 <-- florian has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
20:21:44 <-- FireFly_TB has quit (Quit: FireFly_TB)
20:22:53 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
20:30:03 <flo-retina> nhnt11: Instantbird leaks tons of stuff at shutdown if an awesome tab was open
20:34:31 <-- mconley has quit (Input/output error)
20:42:21 <-- Tonnes has quit (Connection reset by peer)
20:48:43 --> Tonnes has joined #instantbird
20:51:17 <-- rosonline has quit (Quit: Instantbird 1.4 -- http://www.instantbird.com)
21:06:34 <instantbot> florian@instantbird.org requested review from aleth@instantbird.o rg for attachment 2780 on bug 1750.
21:06:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1750 min, --, ---, florian, NEW, Warning: Use of Mutation Events is deprecated. Use MutationObserver instead.
21:14:34 --> mconley has joined #instantbird
21:58:27 <flo-retina> hmm, just adding a mutation observer on the firefox tab bar doesn't trigger the assertion :-S
22:02:04 --> florian has joined #instantbird
22:07:37 <-- florian has quit (Input/output error)
22:11:14 --> qlum has joined #instantbird
22:27:28 --> nhnt11 has joined #instantbird
22:28:05 <nhnt11> flo-retina: :( http://log.bezut.info/instantbird/today/#m604
22:28:25 <flo-retina> happy debugging ;)
22:29:32 * nhnt11 isn't sure how to debug leaks
22:29:44 <nhnt11> I suppose I need to get a debug build ready..
22:30:13 <flo-retina> get a debug build, yes :)
22:30:24 <flo-retina> and find observers that you should be removing but aren't
22:31:50 <flo-retina> it's possibly just a line or two missing from the destroy method
22:32:42 <nhnt11> flo-retina: Do event listeners need to be removed?
22:32:48 <flo-retina> no
22:32:55 <flo-retina> hmm, it may be the stats service that leaks
22:32:58 <nhnt11> Yeah
22:33:03 <-- mconley has quit (Input/output error)
22:33:22 <flo-retina> as the leak happens too if I've closed the awesome tab before shutdown
22:33:46 <nhnt11> But not if no awesometab was ever opened?
22:34:00 <flo-retina> right
22:34:12 * nhnt11 starts a debug build
22:34:29 <flo-retina> hmm, I think I'm starting to guess what happens
22:34:44 <flo-retina> is there a way the stats service could be keeping a reference to the awesometab ?
22:35:00 <nhnt11> Only if the observer isn't getting removed correctly
22:38:01 <flo-retina> I don't see anything wrong in the code dealing with the observers
22:38:05 <flo-retina> that's strange :-S
22:38:40 * nhnt11 doesn't see anything obviously wrong either
22:40:47 <flo-retina> my assertion bug is super strange
22:40:52 <flo-retina> it's unrelated to the mutation observers
22:41:02 <flo-retina> and it happens only when a double click on a conv on hold reopens it
22:41:29 <flo-retina> if I make a simple click reopen, no assertion. If I make it be reopened by triple clicks, no assertion (neither on double nor triple clicks)
22:41:50 <nhnt11> :S
22:44:54 <flo-retina> ahah, I can reproduce with a trunk mozilla-central build!
22:53:11 --> FireFly_TB has joined #instantbird
22:57:54 <flo-retina> hmm, it seems the mutation observer patch for message themes broke system message collapsing on bubble conversations restored from hold :-S
23:01:58 <-- qlum has quit (Quit: Getting the <censored> out.)
23:15:37 --> EionRobb has joined #instantbird
23:17:48 * nhnt11 keeps getting errors trying to compile
23:20:22 <flo-retina> if you are stuck, ask ;)
23:20:34 <flo-retina> or if you want me to try and debug the leak
23:21:18 <nhnt11> I don't get why I'm getting so many errors
23:21:28 <nhnt11> I had a debug build before, it worked fine
23:21:28 <flo-retina> want to pastebin some?
23:21:31 <nhnt11> Yeah
23:24:46 <nhnt11> http://pastebin.instantbird.com/304219
23:25:09 <nhnt11> I didn't see anything relevant above that but I can pastebin the whole thing if you want
23:25:18 <flo-retina> have you clobbered?
23:25:22 <nhnt11> yeah
23:25:26 <nhnt11> It's a fresh debug build
23:25:27 <flo-retina> is your mozilla/ up to date?
23:25:33 <nhnt11> As far as I know, yes
23:25:42 <nhnt11> i'll do an update..
23:25:52 <flo-retina> what does "hg -R mozilla parent" say?
23:25:58 <flo-retina> is this a revision on the moz22 tag?
23:26:22 <nhnt11> yeah
23:26:31 <nhnt11> lmpbtfy
23:26:47 <nhnt11> http://pastebin.instantbird.com/304220
23:26:59 <flo-retina> yeah, that's correct
23:27:16 <flo-retina> clang --version ?
23:27:43 <nhnt11> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
23:27:53 <flo-retina> I have the exact same
23:27:55 <flo-retina> :-S
23:28:16 <flo-retina> anything strange in your mozconfig?
23:28:39 <nhnt11> I have the default mozconfig with valgrind removed
23:28:45 <flo-retina> ok
23:28:54 <nhnt11> oh and I removed the line for the inspector
23:28:55 <flo-retina> I hope you also tweaked the -j setting :)
23:28:59 <nhnt11> Yeah it's -j8
23:30:19 --> mconley has joined #instantbird
23:30:36 <nhnt11> tier_app works fine
23:30:53 <flo-retina> err, what?
23:31:02 <flo-retina> tier_app shouldn't work if you haven't built Mozilla first
23:31:23 <nhnt11> flo-retina: tier_app works on my existing objdir
23:31:26 <nhnt11> not the debug one
23:31:29 <flo-retina> ok
23:32:14 <-- FireFly_TB has quit (Ping timeout)
23:32:52 <flo-retina> the observer is correctly removed
23:32:59 <flo-retina> there must be something else :-S
23:33:21 <nhnt11> Hmm
23:33:30 * nhnt11 wonders if he needs an Xcode update or something
23:33:58 <flo-retina> your clang is at the most recent version already
23:34:19 <flo-retina> I had to update to that version, but that was to build mozilla-central (moz26), not Ib (moz22)
23:35:34 <nhnt11> I wonder what I've borked...
23:36:08 <flo-retina> wasn't there something else that you had to fix recently?
23:36:30 <nhnt11> What? No..
23:49:54 <flo-retina> what's       if ("observe" in observer) // Avoid failing on destructed XBL bindings. ??
23:51:15 <nhnt11> flo-retina: I copied that from the buddy list code, but I don't think it should ever be necessary :-/
23:52:56 <flo-retina> aaaaaah!
23:53:02 <flo-retina> I know the problem
23:53:06 * nhnt11 waits for the revelation
23:53:26 <flo-retina> addObserver adds the observer to the _observer array in the prototype
23:53:44 <flo-retina> but removeObserver creates a new filtered array
23:54:34 <nhnt11> :S
23:54:47 <nhnt11> So the old array gets leaked?
23:54:59 <flo-retina> the old array is kept in memory forever
23:55:16 <flo-retina> and keeps a strong reference to the newtab binding (ie to the conversation window)
23:55:19 <nhnt11> flo-retina: Shouldn't this problem exist elsewhere too then? Considering I copied all this code
23:55:32 <flo-retina> you miss copied it
23:55:38 <nhnt11> oh
23:55:46 <nhnt11> ah
23:56:59 <nhnt11> Would putting this._observers = [] in the constructor fix it?
23:57:10 <nhnt11> Or should I just change all of this to use a Set
23:57:11 <flo-retina> I think so (trying)
23:57:18 <flo-retina> a set of observers?
23:57:26 <nhnt11> yeah
23:57:27 <flo-retina> sounds scary :-D
23:57:40 <nhnt11> lol