#instantbird log on 06 21 2011

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