=== jono is now known as Guest14995 [06:09] good morning all [06:35] good morning [07:17] Hello dholbach, dpm [07:18] hey nigelb, morning! [07:21] Good Morning [07:40] hi nigelb [07:46] dholbach: How're you doing? [07:47] good good - how about yourself? [08:35] dholbach: Having a tiring day, otherwise ok :) [08:45] * dholbach hugs nigelb [08:52] * nigelb hugs dholbach back === dholbach_ is now known as dholbach [15:00] jono, I'll be 2 mins for the team call [15:03] dpm, np [15:04] mhall119, call? === dholbach_ is now known as dholbach [16:00] elfy: IS is aware of your two tickets and are in progress [16:07] jcastro: cheers :) [16:07] almost said awesome ... :p [16:07] \o/ Awesome! [16:07] :) [16:34] jcastro, why does discourse use referrer links in emails? grr [16:35] because they send via sendgrid? [16:35] yeah, we're (me, because I'm lazy) is using sendgrid [16:36] I'm working on a real email server so you can just reply via email [16:37] ohh marcoceppi that would be cool.. it's not a big deal, I stripped the ref link.. just annoying to see more and more of them. It's disconcerting from a user experience perspective. only a few years ago only people trying to scam you nested links like that.. now google does it on every search result (if you let them) [16:41] heheh [16:41] hippie ㋛ [17:40] <-- lunch [17:44] <-- lunch [17:44] whoops, wrong channel [17:45] I just thought you were very excited about lunch === LordOfTime is now known as LordOfTime|EC2 [18:11] I am [18:11] pleia2: ask me why! [18:11] jcastro, why were you so excited about lunch? [18:11] because I had like 7 tacos [18:11] haha [18:12] jono: this mcaffee video [18:12] lol why does he have guns === dpm is now known as dpm-afk [20:06] jcastro: you got any idea where unity-lens-shopping has gone in saucy - want to try and head a thread off before it degenerates ... [20:30] marcoceppi, I'm not seeing the webapps stuff at all. I went looking for the code, but the build progress compresses and minifies everything so I don't know whether it's not there or I just can't find it ;) [20:33] aquarius: it's still there http://i.imgur.com/FEnjvDH.png [20:33] just really hard to read :) [20:33] nice [20:33] let me see if I can see that :) [20:35] er! [20:36] at the point at which the script runs, external.getUnityObject doesn't exist [20:36] once page load is complete, it *does* exist. [20:36] so that's certainly a bug in my code [20:37] clearly we need to wait for both Ember to complete (which we are doing) but also wait for the Unity extension to inject its object into window.external ! [20:37] hrm. I do not know what to wait for, though. [20:37] if I were a miserable sinner I'd just do a setTimeout. [20:37] also, this suggests that it works for marcoceppi because his computer is faster than mine ;) [20:42] I'd ask the webapps team but they're too busy to help :( [21:02] aquarius: it's good to know all this horsepower is good for something :P [21:05] marcoceppi, so... I am not sre what to do, now :( [21:06] aquarius: well it doesn't need to be fixed right now. During tomorrow's maint window I can easily exclude the patch from the "build" process [21:06] if that is indeed what is causing the problem with opera [21:06] * marcoceppi still needs to verify that [21:07] marcoceppi, I'd be surprised if that's what's causing the problem (the script does check that its stuff is there rather than blowing up, which is why it just quietly doesn't work rather than exploding on everyone's browser) [21:07] but maybe I'm wrong and I did cause it, in which case certainly do exclude it :) [21:08] aquarius: right, I haven't seen any bugs in upstream yet regarding this and I feel like people would be quite vocal. Once I unlazy myself and install opera I can do a bit more testing [21:09] trivial although sinful fix: inside document.on("discourse:ready"), wrap the contents in setTimeout(function() { ... contents ... }, 5000) so it just hangs about for five seconds and *then* kicks off the webapps stuff, which should be enough time to convince the unity extension to do its stuff ;) [21:10] I feel so dirty. [23:15] marcoceppi: heh so it really was aquarius [23:15] * jcastro pats aquarius on the back [23:15] no worries man, this is why we prototype [23:16] have we actually established that yet? :) [23:16] good to know you guys found the problem tho [23:16] well, with no popey around who else is to blame? [23:16] hey! marcoceppi is *guessing* that it's my patch which breaks it ;) [23:16] heh [23:16] I am yet to be convinced :) [23:16] the icon you picked looks nice in the launcher btw [23:16] jcastro, oh, the webapps integration works for you, does it? [23:17] it's going to be hot action when it works [23:17] no, it doesn't [23:17] heh :) [23:17] I mean, it detected and installed [23:17] no notifications or stuff yet [23:17] ah, right. I don't even get that. [23:17] oh ok [23:17] because when it tries to do its stuff, the Unity integration hasn't kicked in. For me, at least. [23:26] aquarius: http://test.ubuntu-discourse.org/t/site-doesnt-display-in-opera-and-other-browsers/426/15?u=marcoceppi however, when I moved back to just trunk, opera still breaks [23:26] I'm inclined to say opera is just a PITA and move on [23:27] in any event, I just added if(external && external.getUnityObject(1)) { [23:27] pretty sure that should satisfy that [23:31] marcoceppi, I get a blank white screen in iOS Safari, too [23:32] which might be considered more important tha Opera. :) [23:32] (although Opera is important, man :)) [23:33] that aside -- the external fix won't help, I don't think. The problem is not that we're not checking for external properly, it's that *when that code runs* on my machine at least, external.getUnityObject doesn't exist because the Unity chrome extension hasn't created it *yet*. Once the page is all loaded and everything, that object *does* exist. [23:33] I don't know why the code doesn't work for jcastro, though. [23:34] aquarius: so would it be better to just wait for on document load rather than ember as it appears ember blocks document from laoding? [23:34] marcoceppi, the problem is that that *requires* Ember to block document load. [23:34] and I am not sure that it always does. [23:35] and if docuemnt load fires *before* Ember.Application.ready, then we'll try and do the integration stuff before Ember properly exists, and thus epic fail. [23:35] What we want to do is wait for *both* Ember.Application.ready *and* unity-creates-its-object [23:36] but there isn't an event for the second one ;(