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