All times are UTC.
00:20:30 --> mepine has joined #instantbird 01:56:46 <-- clokep has quit (Quit: Instantbird 0.3pre) 02:11:01 <-- mepine has quit (Ping timeout) 02:24:33 --> mepine has joined #instantbird 03:29:19 --> EionRobb1 has joined #instantbird 03:29:27 <-- EionRobb has quit (Ping timeout) 03:39:13 <-- Chaz6 has quit (Ping timeout) 03:45:50 --> Chaz6 has joined #instantbird 03:56:19 --> waynenguyen has joined #instantbird 04:00:50 <-- Chaz6 has quit (Ping timeout) 04:04:53 --> Chaz6 has joined #instantbird 04:06:38 <-- Chaz6 has quit (Ping timeout) 04:14:46 --> Chaz6 has joined #instantbird 04:34:45 <-- linuxwizard has left #instantbird () 05:08:47 --> sabret00the_ has joined #instantbird 05:09:15 <-- sabret00the has quit (Ping timeout) 05:28:17 <-- waynenguyen has quit (Ping timeout) 05:29:50 <-- EionRobb1 has quit (Quit: Leaving.) 05:40:00 --> Mook has joined #instantbird 05:53:40 --> waynenguyen has joined #instantbird 06:06:14 <-- mepine has quit (Quit: mepine) 06:38:44 --> Mic has joined #instantbird 06:38:45 * ChanServ sets mode +h Mic 06:47:05 <-- Mic has left #instantbird () 06:47:14 --> Mic has joined #instantbird 06:47:14 * ChanServ sets mode +h Mic 06:47:40 --> FeuerFliege has joined #instantbird 06:47:49 <FeuerFliege> hi 06:48:13 <FeuerFliege> any updates on the twitter error 420 bug? 06:52:04 <-- Mic has quit (Quit: Instantbird 0.3pre) 06:52:15 --> Mic has joined #instantbird 06:52:15 * ChanServ sets mode +h Mic 06:53:42 <-- Mic has quit (Quit: Instantbird 0.3pre) 06:56:24 --> mepine has joined #instantbird 06:56:25 <-- mepine has quit (Quit: mepine) 07:01:31 --> Mic has joined #instantbird 07:01:32 * ChanServ sets mode +h Mic 07:04:28 <-- Mic has quit (Quit: Instantbird 0.3pre) 07:04:59 --> Mic has joined #instantbird 07:04:59 * ChanServ sets mode +h Mic 07:19:21 <-- FeuerFliege has quit (Ping timeout) 07:20:01 <-- Mook has quit (Quit: zzz) 07:28:12 --> FeuerFliege has joined #instantbird 07:31:35 <-- FeuerFliege has quit (Ping timeout) 07:36:33 --> mepine has joined #instantbird 07:43:53 <-- chrisccoulson has quit (Quit: Ex-Chat) 07:44:03 --> chrisccoulson has joined #instantbird 07:48:57 --> FeuerFliege has joined #instantbird 07:49:19 <-- FeuerFliege has quit (Quit: Instantbird 0.3pre) 07:51:19 --> FeuerFliege has joined #instantbird 08:08:54 <-- Mic has left #instantbird () 08:23:22 --> FeuerFliege1 has joined #instantbird 08:23:54 <-- FeuerFliege has quit (Ping timeout) 08:25:01 --> flo has joined #instantbird 08:25:01 * ChanServ sets mode +qo flo flo 08:25:25 <flo> hmm, how come after an update my nightly restarted in safe mode? :-S 08:25:27 <flo> (hello! :)) 08:31:14 --> Andrey has joined #instantbird 08:47:40 <-- Andrey has quit (Quit: ) 08:59:42 --> Andrey has joined #instantbird 09:01:54 <flo> FeuerFliege1: no, someone needs to investigate :(. 09:02:45 <flo> clokep: so you mean we miss a "!" in that Yahoo tooltip? 09:02:52 <flo> I copied that from the Adium home page :-] 09:03:25 <flo> Mic: "it would be good if the Coming-soon-text would go away with no replacement then" it will be removed at release-time :). 09:43:26 --> Mic has joined #instantbird 09:43:26 * ChanServ sets mode +h Mic 09:57:55 --> FeuerFliege has joined #instantbird 09:58:37 <-- FeuerFliege1 has quit (Ping timeout) 10:12:08 --> clokep has joined #instantbird 10:12:09 * ChanServ sets mode +h clokep 10:18:18 <-- mepine has quit (Ping timeout) 10:24:48 <clokep> flo: Yes, I mean "Yahoo! Messenger", the link it goes to even says it! :) 10:25:02 <clokep> And when I try to investigate the 420 errors...I don't get them. :( 10:25:14 <clokep> Do we have definite STR? 10:25:55 <flo> no 10:26:04 <flo> I've been connected to twitter for 2 hours without any error :-S 10:28:58 <-- chrisccoulson has quit (Quit: Ex-Chat) 10:31:35 <clokep> Right. 10:33:18 --> chrisccoulson has joined #instantbird 10:38:32 <-- Mic has quit (Ping timeout) 10:39:07 <-- Andrey has quit (Ping timeout) 10:39:16 --> Andrey has joined #instantbird 10:44:39 <-- Andrey has quit (Quit: ) 10:45:18 --> Mic has joined #instantbird 10:45:18 * ChanServ sets mode +h Mic 10:51:59 <-- clokep has quit (Quit: Instantbird 0.3pre) 11:14:41 <-- FeuerFliege has quit (Quit: Instantbird 0.3pre) 11:22:55 <-- waynenguyen has quit (Connection reset by peer) 11:29:33 --> sonny has joined #instantbird 11:38:14 <instantbot> New Instantbird (UI) bug 847 filed by benediktp@ymail.com. 11:38:16 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=847 enh, --, ---, nobody, NEW, Suggesting displayname based on name of logged in user 11:45:16 <Mic> We could also suggest the icon that the user is using for their OS profile (on Windows atleast). I'm just not sure if people would like that ;) 11:47:36 <Mic> ah, why not.. 11:50:57 <flo> :) 11:51:03 <instantbot> New Instantbird (UI) bug 848 filed by benediktp@ymail.com. 11:51:04 <flo> that's something I wanted an forgot 11:51:05 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=848 enh, --, ---, nobody, NEW, Suggesting icon based on icon of logged-in user 11:51:15 <flo> I think there's some code in Thunderbird to detect the username 11:51:43 --> FeuerFliege has joined #instantbird 11:52:07 <flo> the profile icon exists on Mac OS X too (at the first login it prompts to select an image file or to take a picture with the webcam if one is available). Not sure we can find something for linux though. 11:52:15 <Mic> I linked to the docs of the necessary component 11:52:52 <Mic> Ah, no idea about the icon though, maybe we need to write something OS specific 11:53:25 --> clokep_work has joined #instantbird 11:53:26 * ChanServ sets mode +h clokep_work 11:56:48 <flo> Mic: the Windows implementation seems a bit limited: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/nsUserInfoWin.cpp#72 11:56:56 <flo> at least the "username" should work I guess 11:57:21 <Mic> Yes, the Doc says that too 11:59:47 <flo> for the icon, it would be nice to propose taking a picture from the webcam :) 12:02:15 <clokep_work> Yes, that would be nice! :) 12:02:47 <Mic> Is there an API for this already? 12:03:34 <flo> no idea :-/ 12:03:57 <clokep_work> Rainbow. ;) 12:04:09 <clokep_work> (As much as I'm winking, I think that that seriously is the API for it.) 12:06:00 <Mic> bbl, lunch now 12:07:01 <-- Mic has quit (Quit: Instantbird 0.3pre) 12:09:47 <flo> ah, my twitter account is in its error 420 business again 12:10:32 <flo> and it entered that... when I returned from being away, ahah! 12:10:53 <clokep_work> From being away? Hmmm...should being away affect anything? 12:11:07 <flo> it certainly calls your observer 12:11:14 <flo> and that also explains why we keep receiving messages 12:11:25 <flo> we are somehow connecting several times the same account 12:11:47 <clokep_work> OH! 12:11:53 <clokep_work> I know what to do flo. 12:12:04 <flo> I think it's pretty obvious at this point ;) 12:12:12 <clokep_work> aSubject.currentStatusType > Ci.imIStatusInfo.STATUS_OFFLINE & !this.connected 12:12:16 <clokep_work> Was what I was going to say. :) 12:12:29 <clokep_work> For the second if statement. 12:12:35 <clokep_work> But if you have a better fix, let me know. 12:12:43 <flo> shouldn't we add a check before this.disconnect too? 12:12:43 <clokep_work> I can r+ it...if it's good. ;) 12:13:32 <clokep_work> Hmm....perhaps. I'm not sure that would break anything, but it can't hurt to do. 12:13:32 * flo is happy that this is no longer a "WTF happens here?!?" issue :) 12:14:01 <flo> well, if the account is currently disconnected and the user changes the status to offline, you are setting _enabled to true... 12:15:29 <clokep_work> Ah, yes you're right. 12:15:46 <flo> it's also interesting to know why we made that mistake in the first place 12:16:02 <clokep_work> And actually, calling disconnect() if you're disconnected might throw some errors too (mostly harmless ones, but still.) 12:16:10 <clokep_work> Good find flo! :) 12:16:14 <flo> we probably expected that such an error couldn't go unnoticed, because (dis)connect would throw in such bad uses 12:16:31 <clokep_work> That plus poor testing on my part + no testing on your part. ;) 12:17:00 <clokep_work> I tested that status changes worked, but didn't stay connected more then a few minutes, so probably didn't have extraneous tweets coming in. 12:17:18 <flo> well, if you blame the fact that the code is written by humans, it doesn't help much to avoid the future mistakes ;) 12:18:04 <clokep_work> Perhaps connect should throw an error if it's connected? Or just return early? 12:18:14 <flo> I think it should throw 12:18:18 <flo> and disconnect too 12:18:30 <flo> but with explicit error messages 12:19:18 <flo> or a Cr.NS_ERROR code 12:19:29 <clokep_work> "What, are you stupid?! You're already connected!" 12:19:34 * flo will look at what purplexpcom does 12:21:43 <flo> apparently calling disconnect several time does nothing 12:22:06 <clokep_work> In purplexpcom? 12:22:37 <flo> purplexpcom just forwards the call to purple_account_set_enabled in both cases 12:23:01 <flo> almost directly (only Connect can fail, when Mozilla thinks we are offline) 12:23:34 <flo> ok, connecting twice will return early 12:23:59 <flo> I'm not sure anymore that we should throw then 12:24:48 <clokep_work> We don't have to make the same design decisions as libpurple. ;) 12:24:57 <flo> jsProtoHelper only forwards to purpleAccountBase, which returns NS_ERROR_NOT_IMPLEMENTED... not very interesting findings :-D 12:25:23 <flo> clokep_work: right. I made a different design decision: I decided we wanted a consistent API :-P. 12:25:44 <flo> "scnr" ;) 12:26:13 <FeuerFliege> flo: same here, twitter worked for hours, but one change from anline to away and back (in the contact window) and twitter goes rogue 12:26:39 <flo> I'm not sure why changing from available to away didn't cause it first 12:27:47 <flo> or does twitter have a "rate limit" or "you can have at most 2 streaming connection opened at once", which would make the third one fail? 12:27:55 <flo> s/or/of/ 12:28:42 <clokep_work> Hmmm...they must limit the # of streams, but two seems pretty low. 12:29:12 <flo> I don't see any (good) reason to have more than one 12:29:36 <flo> so I could assume 2 could be 1 + 1 that has timeouted at one end but not at the other yet 12:30:10 <clokep_work> I can't either, if you really meant "can have at most 2 streaming connections opened at once per user you're using" 12:30:23 <flo> yeah, per user of course 12:31:43 <flo> http://dev.twitter.com/pages/streaming_api "User Streams: Nearly all data required to update a user's display. Requires the user's OAuth token. [...] A large number of User Streams _may not_ be created from the same host or service." 12:32:10 <FeuerFliege> Do not open *more than a few connections* to User Streams from a server application 12:32:49 --> GeekShadow has joined #instantbird 12:32:52 <flo> "Site Streams: BETA Allows multiplexing of multiple User Streams over a Site Stream connection. Once more than a handful of User Streams connections are opened from the same host or service, Site Streams must be used." 12:33:27 <clokep_work> "few", "handful"...these are technical docs they should be SPECIFIC. 12:34:03 <flo> clokep_work: those are the specific words for "we have no idea of what we are doing so we will change the values without notifying you" ;) 12:34:39 <FeuerFliege> Clients must be prepared to receive a 420 error code that indicates that the account has been logging in too often. This code will be the indication that the account has exceeded the per-account-per-application connection limit described above. 12:35:44 <FeuerFliege> now we know. But if you look up the 420 Error you find something about hundreds connection per hour and so on 12:36:23 <flo> clokep_work: another area of concern is: how come we are displaying "Error: 420 - 420" instead of having the second 420 replaced by the error message that we received from the server (it's visible in the error console) 12:36:43 <flo> FeuerFliege: the hundreds of connection per hour thing is for the REST API 12:37:06 <clokep_work> flo: What is the JSON response we get? Perhaps we're not parsing it right, or perhaps Twitter doesn't send the real error. 12:40:58 --> Mic has joined #instantbird 12:40:59 * ChanServ sets mode +h Mic 12:42:30 <clokep_work> It's possible that ERROR function I added in my patch needs more done to it than just ERROR(e). 12:43:43 <flo> we have another issue 12:44:06 <flo> I connected a test twitter account in my debug build to look at the output in the error console 12:45:53 <-- flo has quit (Ping timeout) 12:52:52 <clokep_work> What issue? ;) 13:02:06 --> flo has joined #instantbird 13:02:06 * ChanServ sets mode +qo flo flo 13:03:51 <flo> I think I've identified the case where automatic reconnections don't work: 1. losing the network connection and having all the accounts disabled (accounts will try to auto-reconnect), 2. having Mozilla discover that the network is down, thus making all the reconnection attempt fail (and after that kind of failure, there's not auto-reconnect). 13:05:30 <clokep_work> Is this a Twitter issue or an everything issue? 13:05:40 <flo> an everything but twitter issue :-D. 13:05:51 <flo> (well, everything but jsProto) 13:06:20 <flo> ah, so my connection dropped way earlier than I thought 13:06:37 <flo> 14:43:43 - flo: we have another issue 13:06:37 <flo> 14:44:06 - flo: I connected a test twitter account in my debug build to look at the output in the error console 13:06:37 <flo> 14:44:26 - flo: things start to go wrong at the 3rd status change (so the 4th streaming connection we open) 13:06:37 <flo> 14:45:20 - flo: at this point, for some reason (I don't understand why yet), we send 8 requests to create new streaming connections 13:06:37 <flo> 14:45:34 - flo: and the next one (so 4+8+1) starts failing with the error 420 13:06:38 <flo> 14:47:03 - flo: the last 2 messages in the console are: 13:06:38 <flo> 14:47:03 - flo: Received response: Easy there, Turbo. Too many requests recently. Enhance your calm. Source File: resource:///modules/jsProtoHelper.jsm Line: 877 13:06:41 <flo> 14:47:03 - flo: Error: 420 - 420 Source File: resource:///modules/jsProtoHelper.jsm Line: 883 13:06:43 <flo> 14:49:18 - flo: I suspect the 9 additional requests are because at the 4th connection twitter starts closing the old one, which we automatically attempt to reconnect. 13:06:46 <flo> 14:49:25 - flo: in this case, it's "right". 13:06:47 <flo> 14:50:44 - flo: in the onError and onStreamError methods, we use only 1 parameter 13:06:50 <flo> 14:51:32 - flo: but the error message is actually given on the second parameter: http://lxr.instantbird.org/instantbird/source/purple/purplexpcom/src/jsProtoHelper.jsm#885 13:08:27 <flo> hmm, it took almost 9 minutes to timeout on my side :-S. 13:09:21 <clokep_work> Yes, IRC sucks. :P 13:09:44 <clokep_work> Ah, I see. So it really needs the second parameterthere, yes. 13:10:14 <clokep_work> But the fix shuld fix the extra 4 connections, since we won't create them in the first place? 13:10:29 <flo> yes 13:10:36 <flo> not sure of what to do for the error message though 13:13:37 <flo> clokep_work: my first idea was: http://pastebin.instantbird.com/802 13:14:08 <flo> but for non-twitter cases, the responseText is usually an HTML error page :-/ 13:14:34 <clokep_work> Right. :( 13:14:42 <clokep_work> We could override the method in Twitter if we really want to. 13:16:08 <clokep_work> We could get rid of the Components.utils.reportError and just let the aOnError method handle that if they want to? 13:16:18 <clokep_work> (And of course handle it in Twitter.js :)) 13:16:23 <flo> what about using the response text only if the reply has the text/plain mime type? 13:17:51 <clokep_work> That should work, as long as servers are sane. 13:18:57 <-- rikki has quit (Connection reset by peer) 13:19:03 <flo> I don't understand that comment: http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIXMLHttpRequest.idl#144 13:19:05 --> rikki has joined #instantbird 13:21:22 <clokep_work> The second half seems to make sense, but not the first half. :( 13:22:26 <flo> hmm, should we really care about that error message for 0.3? 13:23:38 <clokep_work> I'd be OK filing a follow up. 13:23:49 <clokep_work> Blocking Instantbird.next ;) 13:26:31 * flo forgets the "use the mime type" idea 13:26:39 <flo> the twitter server sends: Content-Type: text/html; charset=iso-8859-1 :( 13:27:41 <flo> that's too bad, "Error: 420 - Easy there, Turbo. Too many requests recently. Enhance your calm." looked pretty nice as a message both in the error console and the account manager :( 13:29:05 <flo> (and for additional fun, responseType = undefined) :) 13:29:25 <clokep_work> Yes. It does. :-/ 13:30:40 <clokep_work> Even if we want it for 0.3, it could still be done as a separate check-in while the other stuff should deifnitely be fixed ASAP (or did you already and it'll be in the next push?) :) 13:30:47 <flo> is there a way to "sniff" the response text to avoid its HTML? :-D 13:31:16 <clokep_work> Check for responseText.indexOf("<html") ? 13:31:30 <clokep_work> Check for responseText.indexOf("<html") == -1, rather. 13:33:00 <flo> /<html\b/i.test(responseText) ? 13:34:01 <clokep_work> \b is a word break? Does > count as a word break? ;) 13:34:07 <flo> yes 13:34:15 <clokep_work> Then yes, that'll probably work. 13:34:28 <clokep_work> (Would we also want to check for XML?) 13:34:38 <flo> I was concerned by the case insensitivity of HTML with indexOf ;) 13:34:47 <clokep_work> Yup. I was too. :) 13:34:57 <clokep_work> responseText.toLowerCase().indexOf... ;) 13:35:27 <flo> want /<(ht|x)ml\b/i.test ? 13:35:40 <clokep_work> Yes. :) 13:35:47 <clokep_work> I don't think we want to print out full XML pages either so... 13:35:55 <flo> errr, wait, why would an XML document start with <xml> :-S 13:36:19 <flo> shouldn't we rather search for <!DOCTYPE ? 13:36:45 <clokep_work> No, you should search for <?xml 13:37:06 <clokep_work> DOCTYPE wouldn't find an XML document that does'nt use DOCTYPES, i.e. one that uses XML Schemas instead. ;) 13:37:21 <flo> for HTML5 it's <!DOCTYPE HTML> 13:38:24 <flo> ok, <?xml sounds right 13:38:47 <clokep_work> Assuming it's a valid document. :-D 13:39:06 <flo> well, if we are receiving garbage... 13:39:32 <clokep_work> Garbage in, garbge out! 13:40:25 <flo> http://pastebin.instantbird.com/806 13:41:42 <clokep_work> That should work, I think. 13:42:21 <flo> if it doesn't, it pretends very well during my testing :) 13:42:48 <-- rikki has quit (Connection reset by peer) 13:42:55 --> rikki has joined #instantbird 13:44:45 <flo> now I'm looking at that twitter bug 13:49:32 <flo> I don't understand my comment about _enabled when double disconnecting any more 13:50:46 <clokep_work> Which comment? 13:51:03 <flo> 14:14:01 - flo: well, if the account is currently disconnected and the user changes the status to offline, you are setting _enabled to true... 13:51:32 <flo> (given that we return early if !this._enabled, I don't see how that could have any effect 13:51:33 <flo> ) 13:52:38 <clokep_work> Right. And this._enabled shouldn't be true if we're offline. 13:52:52 <flo> why? 13:53:34 <clokep_work> Wait, I think I'm just confusing terminology now. 13:54:05 <clokep_work> So if you're disconnected, _enabled shuld be false, so if you set to offline, the function shouldn't run, yes. I agree with that. 13:55:28 <flo> and should we delete this._enabled when the user calls cancelReconnection or when disconnecting because of an error? 13:56:32 <clokep_work> Well, what's the expected behavior if I (cancel reconnect or disconnect from an error) and I go offline and then back online? 13:56:40 <clokep_work> They should stay in the state they're in I assume? 13:56:45 <clokep_work> So, probably. Yes. 13:57:08 <flo> the question was "should we do ... *or* ...?" :) 13:57:57 <flo> if we do it when there's an error, it's useless to do it too when canceling the reconnection (as there's no possible reconnection in the first place if there wasn't an error before) 14:00:12 <flo> how do you feel about http://pastebin.instantbird.com/807 ? 14:01:28 <clokep_work> Why is there a "gotDisconnected" method? 14:02:50 <flo> it handles (= display messages about what happened + cleanup) all the cases that cause us to go from a connect{ed,ing} state to "disconnected" 14:03:03 <clokep_work> Hmm...OK. 14:03:23 --> waynenguyen has joined #instantbird 14:03:31 <flo> given how much more work the disconnect method (exposed in the interface) does, it could be the same method 14:03:35 <clokep_work> Ah, I see it. :) 14:03:45 <clokep_work> That's what I was wondering. ;) 14:03:51 <flo> but it seemed odd to have the "disconnect" method be called when it's not an user action 14:04:22 <clokep_work> Right, that's reasonable. 14:04:29 <clokep_work> I think that looks OK, but I can't try it right now. 14:06:48 --> igorko has joined #instantbird 14:07:56 <flo> it seems to work pretty well 14:11:30 <clokep_work> :) 14:21:38 <flo> here is what I have for bug 846. Anybody wanting to review? 14:21:42 <flo> http://pastebin.instantbird.com/808 14:21:43 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=846 nor, --, ---, nobody, NEW, Blank spaces when a contact signs off that was in a collapsed group while signing on 14:23:41 <clokep_work> Looks good. :) All you did was move a line! ;) 14:23:53 <clokep_work> And simplify an if statement to a ternary. :P 14:24:14 <flo> actually, I did a lot more 14:24:30 <flo> then reverted it because I wasn't confident enough in it to land it that close to 0.3 :-D 14:25:38 <clokep_work> Haha, I see. :) 14:25:59 <flo> I tried to add/remove the listener so that it would be there only when needed 14:26:39 <flo> it seemed pretty easy, but when I started wondering which checks I should add to avoid add-ons breaking it... I gave up :) 14:28:06 <clokep_work> :) 14:41:52 <Mic> Does the not-animating when in collapsed group still apply then? 14:42:13 <Mic> (I didn't look at it, this is only a question) 14:42:26 <flo> the patch is a fix for that specific issue 14:42:47 <flo> (and I tested that I could reproduce it without the patch, and couldn't with the patch) 14:43:14 <Mic> I meant if it breaks the not-animating-when-in-collapsed-group behaviour 14:43:41 <flo> that still works 14:43:50 <Mic> ok, looks pretty good then :) 14:46:40 <clokep_work> Those might be the last couple of bugs then. ; 14:46:40 <clokep_work> ;) 14:47:40 <flo> I'm fixing something else 14:49:02 * clokep_work is assuming bug 108 and bug 809 are too dangerous at this point. 14:49:05 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=108 enh, --, ---, nobody, NEW, Show buddy icons in at least one of the default message themes 14:49:06 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=809 nor, --, ---, nobody, NEW, Handle removing a tag from a buddy even when the server ignores our request 14:57:44 <-- FeuerFliege has left #instantbird () 14:58:56 <flo> I'm trying to get rid of the "Quentin is now available." message that I see once per XMPP conversations when his status on a resource that isn't the current used one changes. 14:59:02 <flo> this is what I have: http://pastebin.instantbird.com/809 15:00:36 --> mokush has joined #instantbird 15:02:28 <clokep_work> Does it work? ;) 15:02:41 <flo> I don't have an easy way to reproduce the issue 15:03:08 <flo> but as it's only once per conversation, it's pretty clear that it's caused by the lack of initialization of this.statusType 15:03:27 <flo> in my testing, the patch doesn't break the other "... is now ..." messages displayed in the conversations 15:03:54 <clokep_work> That's good. 15:04:34 <flo> the new default window positions really make things better on a new profile :) 15:08:48 <flo> hmm, moving a facebook buddy seems to work :-S 15:09:08 <clokep_work> It should work until you restart. 15:09:15 <clokep_work> (Unless they fixed their XMPP gateway.) 15:09:29 <flo> it's kept even after a restart 15:09:55 <flo> only deleting blist.sqlite reverted the buddy's tag to "Buddies" 15:10:49 <flo> apparently the XMPP gateway just doesn't include the groups 15:11:07 <flo> so libpurple doesn't change them back, it only puts them in "Buddies" if they aren't in the list yet 15:11:16 <clokep_work> Ah, maybe? 15:11:21 <clokep_work> It includes them if you make custom groups though. 15:11:45 <Mic> I can confirm the custom-group behaviour 15:12:17 <clokep_work> (You have to mark that group as showing in chat too or something I think?) 15:12:26 <clokep_work> Or maybe just a "Show groups in chat" option. 15:17:17 <flo> http://lxr.instantbird.org/instantbird/source/purple/libpurple/protocols/jabber/roster.c#117 15:17:42 <clokep_work> Hah. 15:18:35 --> Even has joined #instantbird 15:18:36 * ChanServ sets mode +o Even 15:21:00 * clokep_work wonders if the spec defines behavior in that situation. 15:24:19 <flo> ok, the Facebook XMPP gateway includes the group only if we have specified a custom one on the website 15:24:35 <flo> and when moving a buddy that's in a custom group, it's moved back at the next connection 15:24:47 <flo> moving buddies that are in the default group ("Buddies") works fine. 15:25:03 <flo> there's no error or particular trouble when the buddy is moved back to the group Facebook knows. 15:27:48 <instantbot> florian@instantbird.org set the Resolution field on bug 846 to FIXED. 15:27:51 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=846 nor, --, 0.3, florian, RESO FIXED, Blank spaces when a contact signs off that was in a collapsed group while signing on 15:28:22 <clokep_work> Yup, so it seems that can wait then? 15:28:44 <flo> yes 15:28:56 <flo> it will be covered by dust by the time someone looks at it :) 15:32:13 <flo> https://bugzilla.instantbird.org/buglist.cgi?quicksearch=sw%3A0.3 is cleaner now :) 15:32:21 <-- GeekShadow has quit (Connection reset by peer) 15:32:43 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/ba8584aa89cd - Florian Quèze - Attempt to avoid some pointless '<display name> is now <status type>' system messages in XMPP conversations when the status changes on another resource. 15:32:44 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/444e8f69b909 - Florian Quèze - Best effort attempt to display error messages returned by the twitter servers. 15:32:45 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/d30455356be8 - Florian Quèze - Follow-up to bug 650 to avoid connecting several times the same twitter account. 15:32:45 --> GeekShadow has joined #instantbird 15:32:46 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/d92090022fc0 - Florian Quèze - Bug 846 - Blank spaces when a contact signs off that was in a collapsed group while signing on. 15:33:20 <clokep_work> :) 15:34:04 <flo> for bug 675 I'll probably have to write a timeout based "solution" :( 15:34:07 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=675 nor, --, ---, nobody, NEW, Sign off transition not starting/finishing 15:34:27 <flo> the other "solution" is to pretend it doesn't exist until someone shows a way to reproduce 15:38:27 <clokep_work> :-/ 15:40:23 <-- Mic has left #instantbird () 15:40:43 <-- waynenguyen has quit (Ping timeout) 15:40:44 --> Mic has joined #instantbird 15:40:44 * ChanServ sets mode +h Mic 15:41:44 <flo> good evening 15:41:48 <-- flo has quit (Quit: Instantbird 0.3pre) 15:56:54 <-- mokush has quit (Client exited) 16:22:03 <Mic> bye 16:22:16 <-- Mic has quit (Quit: Instantbird 0.3pre) 16:42:56 <-- skeledrew has quit (Quit: Instantbird 0.3pre) 16:44:17 --> skeledrew has joined #instantbird 16:48:05 <instantbot> New Instantbird (UI) bug 849 filed by mnguye23@uic.edu. 16:48:07 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=849 blo, --, ---, nobody, UNCO, Startup Crash, Safe-Mode works 16:55:33 <clokep_work> Eek, that doesn't sound good. 17:51:08 <-- sonny has left #instantbird () 17:53:07 --> sonny has joined #instantbird 18:41:15 --> FeuerFliege has joined #instantbird 18:54:50 <FeuerFliege> I donât know if it is a feature or a bug: I have an old twitter account with only two messages to @myAccount. When twitter connects I get a few latest tweets from guys I follow and those two messages (both 150+ days old) 18:55:38 <clokep_work> FeuerFliege: I've noticed that before as well (well a slightly different situation). 18:58:41 <clokep_work> I think it probably is a bug, we should be able to limit based on a "last tweet received" timestamp or ID, can you file a bug please? 18:58:52 <clokep_work> (I'd say CC me on it, but I get all the mail anyway. ;0) 19:00:29 <FeuerFliege> clokep_work: I will file a bug. 19:00:50 <-- GeekShadow has quit (Ping timeout) 19:01:22 <clokep_work> Yeah, I think it's a matter of keeping track of the last thing we received, throwing it in a preference, then sending that with each request we make + saving it again whenever we UnInit. 19:03:30 --> GeekShadow has joined #instantbird 19:04:14 <FeuerFliege> â¦but first I am going to eat something ;) 19:04:16 <-- FeuerFliege has left #instantbird () 19:16:49 <-- chrisccoulson has quit (Ping timeout) 19:35:28 --> chrisccoulson has joined #instantbird 20:06:00 --> harlock has joined #instantbird 20:08:39 <-- harlock has quit (Ping timeout) 20:09:21 --> DGMurdockIII has joined #instantbird 20:10:21 --> harlock has joined #instantbird 20:12:08 <-- harlock has quit (Ping timeout) 20:13:07 --> harlock has joined #instantbird 20:14:48 <-- harlock has quit (Ping timeout) 20:19:00 --> harlock has joined #instantbird 20:22:53 <-- GeekShadow has quit (Ping timeout) 20:23:54 --> FeuerFliege has joined #instantbird 20:30:57 <-- harlock has quit (Quit: Instantbird 0.3b1) 20:32:44 --> flo has joined #instantbird 20:32:45 * ChanServ sets mode +qo flo flo 20:36:06 --> GeekShadow has joined #instantbird 20:37:24 <clokep_work> Good evening flo. :) 20:37:48 <flo> :) 20:40:52 <clokep_work> Any clue about that start up crash? :-/ I ran out of questions to ask (I ssume there's no crash report if the crash reported doesn't appear). 20:41:22 <flo> the machine/system is somehow screwed up 20:41:38 <FeuerFliege> what does safe-mode different on a brand new installation? 20:42:02 <flo> there's either a bad plugin, a bad driver, a virus or an anti-virus (those last 2 categories are almost the same) that loads a poorly written DLL at the very beginning of the process. 20:42:37 <flo> FeuerFliege: I think (but would need to check) that safe-mode prevents all DLL froms being introduced in the process 20:42:54 <FeuerFliege> IIRC it sets all prefs back and disables add-ons, which should not change anything on a brand new installation 20:43:16 <FeuerFliege> ok didnât know that (dll) 20:44:35 <clokep_work> Yes, I knew it did prefs & add-ons and (other stuff), but wasn't sure what the other stuff was. :) 20:45:04 <flo> I would need to check 20:45:08 <clokep_work> I assumed a bad plug-in, which we should really not load plug-ins if that's possible? 20:45:09 <flo> I'm almost sure for the plugins 20:45:59 <FeuerFliege> flo: in firefox plugins stay active 20:46:08 <clokep_work> Yup, I just checked that too. :) 20:46:37 <flo> oh, apparently safemode disables graphic acceleration 20:47:18 <FeuerFliege> oh, that is a good one. That caused most of the trouble with fx4 20:47:19 <clokep_work> Ah, that could definitely be it. 20:47:47 <FeuerFliege> good night! 20:47:53 <-- FeuerFliege has quit (Quit: Leaving.) 20:48:06 <clokep_work> I guess he didn't feel like filing that bug. ;) 20:50:07 <flo> apparently I got a bit confused with the DLL block list 20:51:28 <igorko> i have contacts bug for IRC 20:51:46 <igorko> contacts list is not redrawed 20:51:59 <flo> we can maybe ask the reported to try setting "layers.acceleration.disabled" to true in about:config 20:52:16 <clokep_work> I think it's worth a shot. 20:52:28 <clokep_work> Will that stick through a safe-mode restart? 20:52:56 <flo> why not? 20:53:13 <flo> safemode doesn't reset prefs, it just avoids reading them 20:53:22 <clokep_work> Ah, I see. 20:53:31 <clokep_work> So setting them in safe-mode would let them be written. 20:55:05 <flo> I hope so at least :) 20:56:45 --> EionRobb has joined #instantbird 20:59:26 <clokep_work> Hah, hopefully! :) Otherwise we have to say to edit pref.js. ;) 21:02:24 <clokep_work> Time for me to go, if you don't have time to reply to that bug I'll do it after I get home. 21:02:29 <-- clokep_work has quit (Quit: http://www.mibbit.com ajax IRC Client) 21:35:39 <-- Chaz6 has quit (Quit: brb) 21:57:02 <-- igorko has quit (Quit: Instantbird 0.3b1) 21:57:58 <-- flo has quit (Input/output error) 21:59:41 --> flo has joined #instantbird 21:59:41 * ChanServ sets mode +qo flo flo 22:03:20 --> vicnet has joined #instantbird 22:06:52 <-- vicnet has quit (Ping timeout) 22:44:51 <-- sonny has left #instantbird () 23:16:05 <flo> Good night 23:16:06 <-- flo has quit (Quit: Instantbird 0.3pre) 23:48:15 --> Mathnerd314 has joined #instantbird