[00:00:20] ok [00:49:53] jhobs: ping?? [00:53:27] jdlrobson: pm'd you [00:57:47] guys, i see push notifications are gonna be on the drawing board in Q3... someone poke me about that at some point... [00:58:29] our company develops a closed source push service, so i might be able to give some helpful tips/warnings etc [00:59:20] insight :) [01:01:19] thedj: ohshitileakedtehsourcecode [01:02:18] I'd almost wish [01:03:51] yeah, i'll have to be a bit careful about where and how I help with that, but I can definetly point out some issues you'll have to consider. [01:11:22] BTW. collapsing sections on mobile production have a new glitch [01:12:01] the chevron arrow points down when you first open a page, even though the section is collapsed (and the arrow should thus point upward) [01:12:08] reported on VP/T [01:12:16] * thedj sleeps [07:45:59] morning! [09:22:23] yo [09:22:37] just finishing breakfast [09:33:36] yo [10:28:12] o/ [10:28:25] f'ing net [13:34:04] out for lunch [16:27:02] jdlrobson: hey are you around? [16:30:46] benestar: i think jdlrobson gets on in an hour [16:30:59] thanks :) [16:32:34] np :) [16:35:37] out for lunch (oh, and forgot to say hi!) [16:42:13] bahh irc nick length limits! [16:54:14] hi [16:54:22] jhobs [17:18:38] nobody is pairiing or caring :( [17:19:53] it's been long since we stopped caring [17:27:10] oh I thought that meeting had been cancelled like a month ago [17:28:17] hm, we could also try running tests on a different api level. https://integration.wikimedia.org/ci/job/apps-android-wikipedia-test/648/artifact/logcat.txt [17:31:39] niedzielski: is that the same thing that was going on with your sporadic test failures yesterday? [17:33:00] mdholloway: different i think. https://integration.wikimedia.org/ci/job/apps-android-wikipedia-test/643/testReport/ [17:33:26] mdholloway: i was just wondering if some of the flakier tests might run better on a newer api [18:55:31] benestar|cloud: hey sorry i missed you [18:55:49] phuedx|afk: so where do we want to move related article api too? [19:08:01] kaldari, hi, around? Is there an extension-like mechanism for MW JS, so that community can enhance certain things via common.js ? [19:08:35] Hey yurik. Not sure what you are asking. [19:08:53] can you give me an example? [19:09:35] are you referring to on mobile specifically? [19:10:00] kaldari, for maps, which uses Leaflet, the wikivoyage community may decide to draw restaurants in a certain way. So on leaflet you can say "if geojsoon has property restaurant, draw it with this code" [19:11:13] but otherwise, the community will provide just the geojson (which has geometries), but not extra js code [19:11:47] yurik: You could use common.js to override some JS globals set by maps, and then delay the actual rendering until after common.js has loaded (for example, waiting until document.ready. [19:12:44] kaldari, take a look at http://leafletjs.com/examples/geojson.html -- search for onEachFeature [19:14:10] kaldari, the geojsonFeature variable will be set by my extension, but than right before passing it to the Leaflet, i need to allow community to add options (second argument) [19:14:53] this is not mobile-specific [19:15:32] kaldari, basically i'm replicating most of the http://leafletjs.com/examples/geojson-example.html [19:15:37] yurik: I think you could do that, but you would just need to set up the order of execution carefully.... [19:16:08] right, that's why i wonder if we have a proper hooks mechanism for the frontend [19:16:25] yes, you can use mw.hook() [19:16:57] yurik: https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook [19:18:13] ah, excelente! [19:18:30] so the code on common.js would add a function to the hook to set the options, and then your code would fire the hook before passing it to Leaflet [19:18:57] just make sure that Common.js is loaded before your code that fires the hook :) [19:23:05] kaldari, something like: in commons.js mw.hook( 'mw.ext.Maps.geojson-init' ).add( function( values, callback ) {...; callback(); } ))? and fire it with mw.hook( '...' ).fire( ..., function() {} ); [19:23:23] or is hook firing sync? [19:25:54] usually, you would just do .fire() or fire with a particular piece of content to modify .fire( $variable ) [19:26:18] you shouldn't need to do a callback [19:28:21] so like mw.hook( 'mw.ext.Maps.geojson-init' ).add( function( $foo ) { $foo = 'bar'; } )) in Common.js [19:28:44] and then mw.hook( 'mw.ext.Maps.geojson-init' ).fire( $foo ); from your code [19:28:49] I believe [19:29:28] I've actually only used mw.hook to modify global variables, so I've never actually passed anything with it. [19:32:02] I believe the firing is sync, but I could be wrong [19:32:16] Krinkle would know [19:32:43] ^ yurik [19:32:45] kaldari, thanks!! [19:33:10] should be easy enough to experiment with locally [19:33:15] awesome, i will try it, and bug krinkle ) [19:34:31] jhobs: should i assume you are stuck on https://phabricator.wikimedia.org/T114726 ? [19:42:20] jdlrobson: kind of? I think the fix could be as simple as changing the Page issues tag to display:block, but I'm trying to see if that would break any other pages [19:42:37] that's the tricky part, since it's not a template so I can't just do a "What links here?" search [19:45:16] jdlrobson: Is there an epic phab task for the lead image project? [19:53:02] jdlrobson: nvm I found the workboard [19:56:07] jdlrobson: commented on the task with my concerns [20:11:45] jhobs: just make it display block [20:12:12] jdlrobson: take the easy fix? don't have to tell me twice! ;) [22:39:02] jdlrobson: I'm about to head out, are there any last-minute things you want me to check out? [22:40:54] jhobs: [22:41:08] ill quickly review your patch [22:41:21] ok, it's a one-liner [22:41:57] did you test on tablet and mobile? [22:42:15] any idea how it happened? [22:42:22] looks like it works [22:50:16] jdlrobson: no idea how it happened. I tested on mobile only technically, but I can't see how it would differ on tablet. I'll double check it now though to be safe [22:52:06] jhobs: i'll do a git bisect [22:52:13] just rather be more confident this is the right fix [22:52:50] jdlrobson: looks fine on tablet (sections expanded by default) [22:54:41] I38c17eacc452942aea8942328c7b26cff0e50d99 < jhobs looks like that's what broke it [23:02:48] jdlrobson: I'm not able to git reset to that revision for some reason... [23:02:59] jhobs: not convinced this patch is the right one [23:03:29] jdlrobson: git doesn't even see it as a valid revision for me [23:04:08] oh that's a changeid [23:04:24] c4c486c792b29f39fb7e57ebd90ba260a81b5465 [23:04:26] oh lol, thought you were giving me the revision id [23:05:10] just keen to understand why this fixes it and why it wasn't broken before [23:05:13] as that line didnt change [23:09:12] jhobs: so the commit before the regression the arrow is pointing down when collapsed that and up when expanded. With your commit it's the opposite [23:10:09] jdlrobson: the way the task described it "v" should mean open and "^" should mean collapsed [23:10:23] yeh but that appears to be incorrect [23:10:25] personally I think it should be the other way [23:10:31] yeah that would make more sense [23:13:44] it looks like https://gyazo.com/85239b4e907c9296197343f42a6cb8e3 was the introduction of the Toggler class. So arrow behavior probably just got put in backwards when that class was created [23:13:47] I'll fix it up [23:13:50] woah [23:13:52] wrong paste lol [23:14:05] I meant the revision ID you put above [23:26:19] jdlrobson: should be fixed now. Dunno why the task originally had the backwards behavior, but I should've raised it as an issue when I thought the arrow direction was weird. [23:36:17] ok I'm out. If there's something else wrong with that patch I'll see it in the morning jdlrobson :) [23:59:30] o/