[00:00:19] jdlrobson: operations/mediawiki-config [00:01:20] awjr: gerrit is super slow today.. [00:01:28] :( [00:01:29] 30 KiB/s ! [00:02:42] ok got it [00:02:44] going through the web interface has seemed fine to me - is the clone what's taking forever? [00:02:51] and https://gerrit.wikimedia.org/r/60362 [00:02:58] awjr: yeh clone was taking ages [00:03:07] blech [00:03:07] ok [00:03:28] so as you know config on the cluster is not done with your average LocalSettings.php file [00:04:44] jdlrobson, jgonera: the e3 gang + me and vibha are heading out in a bit to send off munaf with some drinks somewhere nearby. you are cordially invited :) [00:04:58] sure thang - i'll come along for one :) [00:05:01] are you leaving now? [00:05:05] most config of MW variables are managed in two files: wmf-config/InitialiseSettings.php and wmf-config/CommonSettings.php. the former is where you typically define the value a conf variable should have for specific projects; the latter is where you actually set the variable [00:05:08] Maryana_, how much time do we have left? ;) [00:05:21] jdlrobson: in a few minutes, i think. we're trying to find a good place. [00:05:37] mobile web is unusual in that we manage all of our CommonSettings.php-like stuff in wmf-config/mobile.php [00:05:42] i can also text y'all once we're out [00:06:05] Maryana_, ok, let us know when you're heading to the elevator [00:06:08] we do this since we have a ton of conf variables that we manage (as well as other weird bits of logic), so we don't make CommonSettings.php any more painful than it already is [00:06:44] you will know when i come down to 3 to get my stuff :D [00:07:13] jdlrobson: take a look at https://gerrit.wikimedia.org/r/#/c/59949/ [00:09:44] basically InitialiseSettings.php consists of a huge associative array where the key maps to a config var (in the example, 'wmgMFEnableSiteNotice' maps to 'wgMFEnableSiteNotice'), and the arrays within it are project name => config var value [00:10:34] there's no real semantic meaning to the topmost keys in the InitialiseSettings array - but by convention we do 'wmgVarName' for $wgVarName [00:11:13] then, in CommonSettings.php (or in our case mobile.php), we set the value of $wmgVarName to $wgVarName (like in https://gerrit.wikimedia.org/r/#/c/59949/1/wmf-config/mobile.php) [00:12:35] awjr: jgonera : did you guys settle on a task ? [00:12:50] tfinc_, I'm writing it right now [00:12:58] ok [00:13:07] I'll send a preliminary version now and iron out tech details tomorrow before lunch [07:27:12] anyone happen to know why the fancy "Add image to this article" doesn't show up here https://en.m.wikipedia.org/wiki/WACA_%28AM%29 ? [07:28:29] or here https://en.m.wikipedia.org/wiki/Coastline_%28sculpture%29 [07:45:32] maybe MaxSem knows... [07:45:40] maybe [07:45:45] 23 07:27:12 < edsu> anyone happen to know why the fancy "Add image to this article" doesn't show up here https://en.m.wikipedia.org/wiki/WACA_%28AM%29 ? [07:45:48] 23 07:28:29 < edsu> or here https://en.m.wikipedia.org/wiki/Coastline_%28sculpture%29 [07:46:14] i noticed the feature but don't know a thing about it. [07:47:20] it shouldn't show up on pages with infoboxes [07:47:32] cause we don't know how to add pics to them [08:19:51] MaxSem: reason why I ask is I created a little page to highlight local articles that need images [08:20:13] MaxSem: http://inkdroid.org/ici/ [08:20:44] MaxSem: it highlights articles in pink that need an image [08:21:03] MaxSem: but some of them don't have the fancy helper :( [08:24:05] edsu, we're going to slow down with image calls to action because they resulted in a lot of junk uploads [08:25:02] we're currently rethinking the ways we're going to attract new contributions, so all kinds of unexpected changes should be expected:) [08:25:10] MaxSem: oh :( [08:25:34] MaxSem: i'd be interested to hear what 'junk' means [08:27:06] edsu, enjoy: https://commons.wikimedia.org/wiki/Commons:Village_pump#Missing_author.2Fsource_parameters_on_mobile_uploads:_fix_coming :) [08:29:42] MaxSem: thnx! [08:31:36] MaxSem: i took a picture of a sticker that got deleted I guess because I didn't uderstand copyright - it is tricky ... [13:42:37] ooooh [13:42:38] http://shop.geeksphone.com/en/ [13:42:45] "In order to perform site maintenance, our online shop has shut down temporarily. [13:42:46] We apologize for the inconvenience and ask that you please try again later." [13:42:59] brion: hello! :D [13:43:03] heyyyy [13:43:27] mornin? [13:43:41] also, ContentProviders just operate on an URI -> Cursor interface [13:43:51] nice [13:43:55] the projections, etc *can* contain SQL [13:43:58] but don't *have* to :P [13:44:19] it's sometimes the easiest thing to do, but of course, SQL injection via ContentProviders is something you've to be aware of [13:44:35] also note that we're marking all these ContentProviders as 'private' [13:44:35] little bobby tables :) [13:44:42] heh, indeed :) [13:44:45] oh -- do i have to put anything int he manifest for the private content provider? i forgot to check [13:44:53] yup, check the res/xml dir [13:44:58] spiff [13:45:06] and an entry in AndroidManifest too [13:45:12] copy paste stuff, really [13:45:52] should spend some time abstracting those things away [13:46:02] but also need to be careful against becoming an Architecture Astronaut :) [13:46:15] hehe [13:46:22] hm do i need a sync adapter? that seems unnecessary here [13:46:43] nope [13:46:47] you don't [13:46:58] \o/ [13:47:03] ContentProviders are the Models [13:47:08] Activities, SyncAdapters are different views [13:47:09] err [13:47:11] controllers [13:47:12] whatever :P [13:47:32] oh this is driving me nuts; command+w does 'select all' or something instead of closing a file [13:47:56] brion: cmd+, , search for 'keymaps' [13:47:59] you can modify as you please :) [13:48:04] there are plenty of defaults [13:48:07] you might like some of the new ones [13:50:33] there, remapped cmd+w to 'close active editor', now i won't go insane :D [13:53:36] heh :) [13:54:00] brion: i'm using the 'OS X 10.5+' keymap, looks good to me. Maybe try the earlier ones if you didn't like it [13:54:08] brion: sadly their vim plugin is not up to the mark :( [13:54:23] New review: Cmcmahon; "maintenance" [mediawiki/extensions/MobileFrontend] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/60244 [13:54:23] Change merged: Cmcmahon; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60244 [13:54:33] heh [13:55:36] brion: any news froma pple? [13:55:38] *apple [13:55:54] YuviPanda: you usually see and comment on them before i do ;) [13:55:56] but lemme check [13:56:07] Status Waiting For Review [13:56:15] oh apple [13:56:28] you're going to make us wait a week and then reject us on a technicality, aren't you [13:57:24] hehe yeah [13:58:06] YuviPanda: i don't need the Parcelable interface on my Category items do I? I initially copied it over from the contributions class but it doesn't look necessary so i commented it out [13:58:08] safe to remove? [13:58:29] brion: so, you can't really save state between app rotates without it being parcelable :) [13:58:35] or pass things around between activities [13:58:41] hmm [13:58:42] or... anything, really. [13:58:48] but we're only slurping it from our content provider [13:59:02] right, so I'm not too sure if we need it [13:59:05] \o/ [13:59:07] right now [13:59:11] ok i'll leave it commented out in case it has to go back [13:59:19] nah, kill it in a separate commit [13:59:24] heh [13:59:26] so that we can revert that if needed [13:59:31] that's what version control is for \o/ woooo [13:59:34] indeed :) [13:59:46] I'm glad we aren't on gerrit-with-git-pretending-to-be-svn :) [14:00:53] i wish gerrit had better support for patch sets with multiple change sets in them [14:01:06] and…. a lot of other things [14:02:38] heh [14:04:35] brion: also the search should hit the contentprovider too [14:04:49] hm [14:04:56] brion: should look in the contentprovider and the web simultaneously [14:04:59] and not have duplicates [14:05:02] ah yes [14:05:36] i was gonna just have the recent cats displayed only when there's no search [14:05:41] but we could have it search both [14:05:55] brion: we should [14:06:03] recent cats is going to keep increasing forever :) [14:06:07] :D [14:06:21] we should just sort by last used time and display it on no-search [14:06:56] yeah i was thinking of weighting by frequency of use also so i stuck in a counter field, but we don't have to use it immediately [14:07:07] prefix or substring search? i think the api search is prefix only [14:10:07] brion: prefix [14:10:12] brion: yeah, API is prefix only (sucks) [14:10:17] ;_; [14:10:26] brion: we should be consistent, so we'll do substring when we make the API do substring [14:10:26] prefix is easy to implement in the db though :) [14:10:31] k [14:10:32] yup! [14:10:41] and mind the threads :P [14:10:56] use AsyncTasks for any db operation [14:11:08] and stuf [14:11:08] f [14:11:49] i'm so excited to finally not be the sole committer, so i seem to be going overboard talking about it [14:11:53] sorry about that :) [14:13:12] hehehe no worries [14:13:33] yeah i was going to add the fetch to CategoriesUpdater which is an async task [14:13:45] so it shouldn't need to add in a Loader, if i understand, since it's already in a bg thread [14:14:31] yeah, no loaders needed in this case [14:14:36] still getting used to inner classes hiding around :) [14:14:44] yeah, it gets painful after a while [14:14:55] since having them as innter classes is very nice, but having them all be in the same file sucks [14:15:47] iOS usually has you implement multiple 'delegate' interfaces on your controller classes, it's a bit different [14:20:30] brion: ah [14:20:35] yeah, the C# way I think [14:27:20] brion: but for smaller things (event handlers, etc) anonymous inner classes are slightly less painful [14:28:03] obj-c has blocks now, which are similar to functions/closures in javascript. a little lighter-weight to use than anonymous inner classes [14:28:07] but the syntax sometimes is weird [14:28:16] especially if you want to make a variable [14:28:35] i blame apple :) [14:30:18] brion: heh :D [14:30:24] brion: blaming apple works for eeverything :) [14:30:55] :D [14:31:10] "my linux laptop from dell doesn't ship for a week" "apple's fault!" [14:31:50] of course! dem apples, cloggin up the supply lines! [14:32:30] the tubes [14:32:37] literally :P [14:33:42] categorization is still only available on new files right? [14:34:05] brion: yup [14:34:15] but should be extendible to other files at some point [14:34:20] 'soon' as we say ;) [14:34:25] :) [14:35:04] damn, emulator crashed. now i have to go get my real device and a cable [14:35:15] while I'm at it i'll get my glasses, all this text is blurry [14:35:29] heh :) [14:36:14] and i think i'll brew some coffee [14:36:18] and maybe eat some breakfast :) [14:36:28] in the meantime -- my current code https://github.com/brion/android-commons/commits/recentcats [14:36:37] still need to poke things into the content provider when cats get used [14:36:44] but i think most of the plumbing is getting there now [14:36:52] brion: :D [14:36:58] lemme know if anything seems awry [14:37:02] brion: will do [15:15:30] [android-commons] yuvipanda pushed 1 new commit to master: http://git.io/V7whIA [15:15:30] android-commons/master e0c23a6 YuviPanda: Make TemplateRemoveer *actually* remove templates... [15:15:57] Project Android-Commons (mobile) - Nightly builds build #150: SUCCESS in 39 sec: https://integration.wikimedia.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/150/ [15:15:57] yuvipanda: Make TemplateRemoveer *actually* remove templates [15:38:26] hmm [15:38:33] "Commons has crashed" \o/ [15:39:23] oh nice i can just open the "crash report" in my notes app :D [15:39:43] oops nothing created the table, i should fix that [15:46:49] YuviPanda: ok so current version https://github.com/brion/android-commons/commits/recentcats -- when attempting to query the content provider it appears to die with 'no such table'. [15:46:59] looking [15:47:01] i thought there was something that was supposed to create it on demand but i've clearly missed it ;) [15:47:03] thx [15:49:20] [android-commons] yuvipanda pushed 1 new commit to master: http://git.io/VU63TQ [15:49:20] android-commons/master f026bdd YuviPanda: Relicense to Apache License... [15:49:45] Project Android-Commons (mobile) - Nightly builds build #151: SUCCESS in 36 sec: https://integration.wikimedia.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/151/ [15:49:45] yuvipanda: Relicense to Apache License [16:03:21] YuviPanda: i'm gonna head into the office in a bit, will check back in in about an hour [16:21:59] New patchset: MaxSem; "Uber-compression" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60425 [16:22:45] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60425 [16:45:28] hey mobile team. i still see an old Apache config in our ops puppet repo for a ServerName wap.wikipedia.org but it's NXDOMAIN in DNS. delete? redirect? [16:46:25] hmm.. but "templates/varnish/mobile-frontend.inc.vcl.erb: /* Rewrite .wap.wikipedia.org to new mobile site */ [16:47:04] so en.wap works, etc. it's just the pure wap.wikipedia.org without language [16:51:22] mutante, yes - wap should be left as a b/c redirect [16:52:38] ok, but we would have to create it, currently it doesn't even resolve [16:53:09] mmm, let's wait for tfinc then [17:03:19] MaxSem: ok, thanks, let's do via some ticket [17:06:09] YuviPanda: Right, in here maybe, since #mediawiki is a tad offtopic. Should I fix up that commit to apply on latest master, and check for the '|' case? [17:06:28] nah, I think the | case is a red herring. [17:06:36] yours was failing for unrelated reasons. [17:07:16] i'm heading out to get some dead-tree printing done, will fix it once i'm back [17:07:20] brion: i sent email about the sqlite issue [17:08:03] YuviPanda: yeah i'll fix it up while you're out :) [17:16:22] YuviPanda: Well, I'd love to test it myself, if you have a simple-ish way to do that [17:21:05] jgonera: what is the current status of https://mingle.corp.wikimedia.org/projects/mobile/cards/449 ? [17:22:40] awjr, it's finished (graph in dashboard + summary email on mobile-tech) [17:22:48] sweet! thanks jgonera [17:28:36] YuviPanda: so I thought this might do it: https://github.com/brion/android-commons/commit/79f6185f8c7a245f18af080c9b5a425f8499b2b6 but it's still not creating the table [17:29:08] jcmish, Maryana: fyi i updated the story wall in mingle to point to the current iteration; there are still some cards in testing/ready for signoff on the 'previous iteration story wall' [17:29:30] yup I'm moving those now awjr [17:29:36] thanks jcmish :) [17:29:46] you bet [17:31:16] brion: have some layout possibilities to run by you [17:38:49] MaxSem or brion do you know where namespaces are defined in MW? [17:39:06] namespaces as... [17:39:14] awjr: names or constants? [17:39:18] constants [17:39:23] yeah where NS_FILE is defined [17:39:25] defines.php [17:39:26] for instance [17:39:30] ahha thanks [17:39:41] * brion hands awjr a copy of grep :) [17:40:03] awww i was grep'ing like made before i asked [17:40:12] my grep-fu apparently is not strong today :( [17:40:36] damn i swear i did grep 'define( 'NS_' [17:40:45] awjr, i'm gonna have to test some of these in production, cos beta labs was being weird yesterday [17:40:53] that's OK Maryana [17:41:39] awjr: you probably didn't put enough backslashes on the '(' :) [17:41:52] i always mess those up [17:41:57] \\\\\\\\\\\\\( [17:42:01] ehehehehe [17:42:33] i actually probably totally forgot to put any [17:42:45] * awjr reaches for more coffee [17:43:51] jdlrobson: you guys are pushing the CN change to mobilefrontend today? [17:44:56] mwalker: we were just talking about you [17:45:04] aah! [17:45:08] it's not my fault! [17:45:10] >.> [17:45:10] we are. can we meet at 4pm today to enable it? [17:45:10] <.< [17:45:20] sure [17:45:28] sweet i'll get a calendar invite setup [17:50:51] mwalker, should we leave another note on the VPT, just in case? [17:51:42] probably not a bad idea [18:08:25] marktraceur: so debugging your patch [18:08:36] marktraceur: problem is that openFound will *always* be false [18:08:56] marktraceur: since curIndex is set to the end of {{ [18:09:39] YuviPanda: Unless it's of the form {{template|{{echo|something}}}} [18:09:49] YuviPanda: Which is sort of the point of the whole loop [18:10:12] hmm [18:10:21] let me mess around with it a bit [18:10:43] i've actually figured out how to fix the *original* code so that it works... [18:10:50] Hm. [18:10:59] hmm [18:11:00] actually [18:11:00] YuviPanda: Maybe if I can see that patch, I can fix my patch too [18:11:01] maybe not [18:11:02] hmm [18:11:05] Hah. [18:11:06] yes [18:11:15] brion: the animation looks awesome! [18:12:03] marktraceur: okay, I just realized that if I do what I had in mind I essentially end up at your patch. [18:12:10] Heh. [18:12:12] Today's not been a good day for my brain, me thinks [18:12:13] :D [18:12:19] * YuviPanda applies patch again [18:12:29] brion: i'll finish up this patch and then get back on the sqlite case [18:12:30] * brion patches YuviPanda's brain [18:12:32] thx [18:13:45] marktraceur: and re: testing this elsewhere, I should really extract the entire modifiers bits into a separate library that can be used anywhere.. [18:13:48] * YuviPanda adds that to long list of things to do [18:14:10] *nod* [18:15:56] marktraceur: right, so the problem is that when openFound is false, calling openMatch.start throws an exception [18:16:17] * marktraceur looks [18:16:17] jdlrobson, is there an AJAX request that we make on every page? Diederik is wondering how he could detect non-JS devices based only on server logs [18:16:32] Oh, yeah, I'm dumb [18:16:34] * marktraceur fixes [18:18:00] jgonera: why not use UAs for that? [18:18:45] awjr, yes, I guess we could, I think not many people disable JS [18:19:06] oh yeah, disabled JS… that's a good point though [18:19:15] it would actually be nice to know how many of our users *do* do that [18:19:21] I wonder why Diederik keeps sending those e-mail to a limited group of people though, instead of sending them to mobile-tech [18:20:45] YuviPanda: Pushed to my fork again...I guess I should rebase it [18:20:51] nah it's fine [18:20:57] i'm doing am on a different bit [18:20:59] wait up [18:21:02] don't rebase actually [18:21:06] Oh K [18:23:09] ok i'm starving, i'm going to go burrito up [18:23:11] bbiab :) [18:24:18] marktraceur: hmm, did the push go through? I don't see it on https://github.com/wikimedia/android-commons/pull/7 [18:26:39] YuviPanda: https://github.com/wikimedia/android-commons/pull/7/files has the latest change - note I took out openStart and closeStart [18:27:45] marktraceur: oh, wait. you just ammended and force pushed? [18:27:53] okay, that threw me off [18:28:26] Yeah [18:28:37] * marktraceur is ruined by Gerrit's workflow [18:28:56] jgonera: the obvious one would be looking at javascript modules loaded [18:29:26] marktraceur: bad marktraceur, bad, bad :P [18:29:31] jdlrobson, good point [18:30:08] gerrit is not a very endearing name; sounds like an angry frog [18:30:21] jdlrobson, can you add that to the thread "Re: Collecting metrics regarding javascript support on mobile devices" on mobile-tech? [18:35:35] oh nice. WMF WiFi reaches to chipotle [18:50:58] jdlrobson, mwalker: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Mobile_CentralNotice_banner_going_out_today_to_en.m.wpf [18:50:58] err [18:50:58] http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Mobile_CentralNotice_banner_going_out_today_to_en.m.wp [18:51:04] there we go [18:52:53] one hour before the deployment - is everyone's stuff you want to deploy ready? [18:53:03] awjr, jdlrobson, dr0ptp4kt ^^^ [18:54:26] jdlrobson: https://gerrit.wikimedia.org/r/#/c/60362/ still needs to be updated [18:54:37] MaxSem, yes on Zero. cdd52fa249661cc10ef06289c19f8f274c9a1ed9 'production' branch of ZeroRatedMobileAccess. [18:55:15] MaxSem: i think we should hold off on https://gerrit.wikimedia.org/r/#/c/59553/ until https://gerrit.wikimedia.org/r/#/c/60339/ gets pushed [18:55:36] YuviPanda: looks like those banners brought in a few new Android users, although no prolific uploaders. [18:55:38] sure [18:56:33] YuviPanda: poke [18:56:43] brion: pokeback [18:56:48] ragesoss: yes! hopefully they stick on [18:57:05] YuviPanda: what's the best category to see all mobile WLM uploads ? [18:57:09] brion: --^ [18:57:16] hmm, let me look [18:58:04] tfinc: Category:Uploaded with Android WLM App [18:58:19] tfinc: link https://commons.wikimedia.org/wiki/Category:Uploaded_with_Android_WLM_App [19:04:01] brion: found a list of 10 other iOS browsers... [19:04:29] lol [19:05:56] YuviPanda: ok actually i think it's working now, it creates the db on my nexus7 \o/ [19:05:56] marktraceur: https://test.wikipedia.org/w/index.php?title=File:Killor_mollor.png&curid=69245&diff=170048&oldid=170044 :) [19:06:01] brion: whee :) [19:06:03] i'm getting a new different crash [19:06:06] so that's.. something [19:06:07] brion: ah, nice :) [19:06:32] do poke me if you want to :) [19:11:48] will do [19:16:41] marktraceur: pushed :) [19:16:58] [android-commons] yuvipanda pushed 2 new commits to master: http://git.io/Nwu7ZA [19:16:58] android-commons/master f941989 YuviPanda: Revert "Make TemplateRemoveer *actually* remove templates"... [19:16:59] android-commons/master 6dae336 Mark Holmquist: Make template removal work properly [19:17:53] marktraceur: <3 thank you [19:18:03] Project Android-Commons (mobile) - Nightly builds build #152: SUCCESS in 1 min 14 sec: https://integration.wikimedia.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/152/ [19:18:03] * yuvipanda: Revert "Make TemplateRemoveer *actually* remove templates" [19:18:04] * yuvipanda: Make template removal work properly [19:22:49] YuviPanda: ok i fixed my basic issues i think: https://github.com/brion/android-commons/commits/recentcats [19:22:59] * YuviPanda looks [19:23:08] it now saves selected categories into the db, and shows them (unordered) when the search box is empty [19:23:19] still need to limit the number, sort, and show on initial screen display [19:23:43] New review: Jdlrobson; "(6 comments)" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58997 [19:24:05] brion: should i leave comments inline or to you? [19:24:09] as in [19:24:10] on IRC? [19:24:25] YuviPanda: inline is fine [19:24:28] ok [19:27:20] brion: done [19:27:30] brion: not really doing a full in depth CR but just dropping notes now and then [19:27:33] brion: will dot aht before the emrge :) [19:27:38] that's just fine :D [19:28:08] sweet [19:30:48] YuviPanda: is getContentResolver also expensive or is that ok to run on each async lookup? [19:31:09] getContentResolver is fast, but by itself it is useless, no? [19:31:13] you usually want to do *something* with it [19:31:19] yeah we query it :) [19:31:25] so that should be fine [19:31:31] right, so if you know exactly which contentprovider you are going to query [19:31:36] yous hould get a ContentProviderClient [19:31:39] and use that [19:31:56] brion: there's perf difference between querying directly from ContentResolver vs querying from a particular ContentProviderClient [19:32:16] the latter doesn't have to figure out which content provider it is trying to query, etc - so faster. [19:33:20] ah [19:33:22] spiffy [19:33:41] spiffy indeed :) [19:33:57] New patchset: Jdlrobson; "Make the universe explode by making a desktop AND mobile skin called Minerva" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58997 [19:33:58] New patchset: Jdlrobson; "Promote addToBodyAttributes to desktop skin" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58257 [19:33:58] New patchset: Jdlrobson; "Code move: Lift and shift html rendering to MinervaTemplate" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58996 [19:33:58] New patchset: Jdlrobson; "Move header to generic MinervaTemplate" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58994 [19:34:49] MaxSem: did you see my mail about skin/MobileFormatter stuff? [19:35:11] yes, was a bit confused [19:35:21] * MaxSem re-reads it [19:35:24] heh my testwiki stream has like 12 pictures of the ceiling over my desk cause i'm taking pics with the up-facing camera on the nexus7 [19:35:24] New review: Jdlrobson; "(1 comment)" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58257 [19:35:48] brion: :D [19:35:59] brion: still better than my stream, which is an endless stream of a bloody panda [19:36:12] it is a nice image because it is small and uploads pretty fast [19:36:15] hah [19:36:44] oops forgot to call super on onDestroy [19:37:53] heh :D [19:38:34] this may be the best WLM upload to date http://commons.wikimedia.org/wiki/File:Templo_de_Santa_Teresa_la_Antigua_2012-09-30_15-59-39.jpg [19:38:35] :D [19:38:58] * YuviPanda expects a penis [19:38:59] nice [19:38:59] ah [19:39:00] no [19:39:04] wah [19:39:04] nice [19:39:13] verynice [19:39:27] YuviPanda: victor and i are adding our favs to http://commons.wikimedia.org/wiki/User:Victorgrigas/awesomeness [19:39:34] he'll use it for stuff after [19:39:35] yeah, saw the globalusage link [19:39:38] nice! [19:41:26] YuviPanda: this looks ok? seems to work :) https://github.com/brion/android-commons/commit/d9746307047d4fa80e0f256759add0567b680e00 [19:41:34] * YuviPanda clicks [19:42:29] YuviPanda: Yw [19:42:35] marktraceur: thanks :) [19:43:33] brion: looks nice-ish :) [19:43:36] do you want me to test and merge? [19:43:37] \o/ [19:43:51] not just yet, needs the limits or the list will expand forever [19:43:55] heh [19:43:59] brion: well, the saving should expand forever [19:44:02] and we should add tests [19:44:03] err [19:44:03] search [19:44:08] tests? pssssssh [19:44:14] i meant search :P [19:44:19] :) [19:44:20] but we *should* add tests at some point [19:44:33] brion: also do you have the android key? [19:44:46] YuviPanda: i believe i have it somewhere [19:44:50] same one we used on the other apps? [19:44:56] yuppers [19:45:05] great, then i can push versions when you're gone in theory [19:45:10] be carefula bout losing it / storing it on unencrypted volumes, since if we lose it we *can not* revoke the key [19:45:20] i'll try one before you leave :) [19:45:21] heh [19:45:32] brion: heh, yeah. But there needs to be modifications for the release version. there's a text file in the repo on what to do [19:45:42] ah right, fixing the urls and such [19:45:42] brion: if you just build sign and release, BAD THINGS WILL HAPPEN! [19:45:46] yuppe [19:45:52] and testing the upgrade path [19:55:39] [android-commons] yuvipanda pushed 1 new commit to master: http://git.io/oTiXuw [19:55:40] android-commons/master f721b16 YuviPanda: Prevent upload status from overlapping with the title of upload... [19:56:54] Project Android-Commons (mobile) - Nightly builds build #153: SUCCESS in 1 min 26 sec: https://integration.wikimedia.org/ci/job/Android-Commons%20(mobile)%20-%20Nightly%20builds/153/ [19:56:55] yuvipanda: Prevent upload status from overlapping with the title of upload [19:58:23] YuviPanda: besides you does anyone else on the team know how http://mobile-reportcard.wmflabs.org/ works ? [19:58:44] tfinc: jgonera has worked on it before [19:58:50] and ori-l too [19:59:12] milimetric is the one who has been supporting us with limn related questions [19:59:40] k [20:00:24] YuviPanda: i'm on the hangout [20:00:29] New review: Jdlrobson; "Brion - do you have any ideas / opinions?" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60093 [20:00:37] * brion looks [20:03:39] awjr_lunch, jdlrobson, jgonera, dr0ptp4kt, yurik_ - new MF and Zero are live on testwiki, please test:) [20:03:47] w00t! [20:04:25] anyone got the git log link again (still not in calendar invite) [20:04:43] ^ awjr MaxSem [20:04:57] https://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments/2013-04-23 [20:05:00] jdlrobson: ^ [20:05:04] http://www.mediawiki.org/wiki/MobileFrontend/Deployment < btw this is confusing [20:05:18] thanks awjr [20:05:19] New review: Brion VIBBER; "What I'd probably recommend is making sure that section data from the ParserOutput objects get added..." [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60093 [20:05:35] whoa that looks like a srsly legacy page [20:05:40] what do i need to get this link in the calendar invite. [20:06:20] i think i emailed rachel about it when you last brought it up, it must've fallen off her radar - i'll ping her again [20:07:01] oh, actually, maybe she added it to the old calendar invites which have been replaced by those managed by greg. [20:07:58] hey jgonera, can you modify limn-mobile-data to take into account the new schema being used to record mobile web uploads? [20:08:09] the 'current uploads' has flatlined for a few days since you guys switched it over [20:08:17] jdlrobson: in the meantime though, maybe you should just bookmark the page [20:08:22] shouldn't be too hard [20:08:24] YuviPanda, will do after deployment, didn't know about that [20:08:31] YuviPanda, should I join the two tables...? [20:08:52] jgonera: you need a UNION. I've been doing it for the App Uploads tables for a while [20:08:55] jgonera: look in the config [20:09:08] jdlrobson: i just emailed greg [20:09:15] you need to supply default value for the newly added columns and then everything should be fine [20:09:22] YuviPanda, ok, will do that later [20:09:23] thanks awjr [20:09:33] awjr: i bookmark nothing :) [20:09:38] Maryana: jgonera is going to take care of updating the dashboard with the new schema :) [20:09:48] w00t [20:09:50] thanks! [20:09:57] :) [20:10:57] tfinc: who is going to take responsibility for http://commons.wikimedia.org/wiki/Commons_talk:Mobile_app while i'm gone? [20:11:33] probably i should do that since i'll be doing the app maintenance [20:12:32] brion: watchlist it, yo :D [20:12:55] it's on my wl, lemme adjust my email settings cause i don't think i'm getting notifications [20:13:27] * brion checks Email me when a page or file on my watchlist is changed  [20:13:29] :D [20:13:41] jdlrobson: i'm not sure how to test this https://bugzilla.wikimedia.org/show_bug.cgi?id=44959 [20:14:01] can you check to make sure we've covered all their requests? [20:14:47] YuviPanda: wow that's a lot of bouncing wikipedia globes http://commons.wikimedia.org/wiki/File:Bouncywikilogo.gif#filehistory [20:15:11] okay that was hilarious [20:15:34] yessss http://commons.wikimedia.org/wiki/File:Wikipedialogoexsplode.gif [20:15:49] :D [20:15:51] win [20:15:58] alright, i'm off for a bit. brb in about 20 [20:16:09] enjoy [20:16:17] mins I mean :P [20:16:28] brion: okay, so i'd want you to make a release once the categories stuff is done [20:16:34] ok [20:16:34] Maryana: not entirely sure - guessing someone like siebrand or aharoni would be good people for that [20:16:36] before end of week? [20:16:43] and since no release on friday, thursday? [20:16:58] YuviPanda: thursday morning should be ok [20:17:05] \o/ [20:17:13] <3 [20:17:16] ok, now brb [20:17:17] middle of the day i'll be out at the microsoft store opening. :) gonna pick up some more test devices [20:17:29] Як справи? [20:17:44] aharoni: translate wiki open tickets for MobileFrontend should be fixed [20:19:04] Status In Review \o/ [20:20:12] awjr: jgonera has found a slight rendering problem - probably not a big deal though [20:20:19] ?? [20:20:24] MaxSem, looks good on the ZeroRatedMobileAccess front in TEST. [20:20:27] (special pages have 2 bottoms borders in their headers) [20:20:38] is it just the special pages? [20:21:40] im not sure im seeing it, but maybe i am - it looks like one of the two bottom borders doesn't go 100% across the page [20:21:44] is that correct? [20:22:03] jdlrobson, jgonera ^ [20:22:26] it just looks like a shadow, or extra-thick border-bottom? [20:23:01] sorry guys I was so busy working on the automation scripts I didn't realize my irc connection died [20:23:07] we live on test? [20:23:07] awjr, yes, that's it [20:23:19] jcmish: yes [20:23:19] awjr, extrathick, not 100% [20:23:48] jgonera: yeah ok - didja show Maryana? my feeling is it's not a big deal - it's not particularly noticable (and i kinda like the thicker border anyway...) [20:24:36] quick question [20:24:52] to get wikibase client to work, I need to install wikibase first [20:25:17] pragunbhutani: i think you might be asking in the wrong channel :) [20:25:17] Maryana says it's fine for now [20:25:24] oh sorry [20:25:27] pragunbhutani, #wikimedia-wikidata [20:25:35] pragunbhutani: no worries, this is #wikimedia-mobile [20:25:35] jdlrobson: looking [20:25:38] awjr: the next part of the question will be in this channel [20:25:41] yeah, but nobody show vibha ;) [20:25:46] heh ok pragunbhutani [20:25:51] Maryana: ha [20:25:55] awjr: MF + wikidata [20:26:07] oo [20:26:33] I'm trying to test it out before I frame my gsoc proposal :) [20:26:46] cool! i haven't heard of anyone else trying that yet [20:27:09] I got suggestions from the IRC to see if MF can work with wikidata [20:27:34] i am very curious to hear how that goes [20:27:34] and then the results of that can be used to see what exactly is needed to mobilize wikidata [20:27:57] I will have to consult this channel, eventually [20:28:01] will let you know :) [20:28:36] we'll be here, pragunbhutani :) [20:32:28] out of curiosity, who'll be mentoring that project? [20:32:36] someone from wikimedia-mobile or wikidata? [20:32:49] because it seems to be a cross between the two [20:33:42] should be some WD developer as 99% of it will be inside of Wikidata [20:35:18] jdlrobson: https://gerrit.wikimedia.org/r/#/c/60362/ still needs to be fixed [20:35:39] awjr: can you fix whatever needs fixing currently testing on some obscure browsers [20:36:11] sure jdlrobson but please take a look at what went wrong in that patchset when you get a chance [20:36:21] will do [20:39:02] ahh, so many opera mini bugs! [20:41:25] MaxSem: gotcha :) [20:42:33] jdlrobson, MaxSem: https://gerrit.wikimedia.org/r/#/c/60362/4 [20:45:48] awjr, live on testwiki [20:46:44] ruh roh [20:47:05] i'm seeing a banner to download the android app… but i'm on an iphone :-/ [20:47:47] i was seeing one with desktop chrome [20:48:07] but now i can't seem to trigger it again :-/ [20:48:40] oh right, beta [20:48:55] yeah, i see the banner when im logged in to beta on desktop chrome [20:48:57] jdlrobson: Mobile-frontend-save-settings - is this addressed somehow? [20:49:06] https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Mobile-frontend-save-settings/en [20:49:23] jdlrobson ^^ [20:49:28] aharoni: looking [20:50:08] jdlrobson: the CN banner appears to be targeting all platforms, not just android on testwiki [20:50:16] aharoni: i updated the qqq code but I didn't specify limited space [20:50:19] i simply said " 'mobile-frontend-save-settings' => 'Text for button for saving settings on Special:MobileOptions. Since this appears on the settings page translating the word save is sufficient [20:50:20] {{Identical|Save settings}}'," [20:50:27] awjr: yeh i know test wiki is setup differently [20:50:44] awjr: Maryana the test wiki banner is targeted at everything [20:51:03] jdlrobson: is it possible to set it up like it will be in production so we can test if it works right? [20:51:33] done [20:51:46] (well asked walker to do so awjr) [20:51:58] yah thanks jdlrobson [20:52:02] * YuviPanda heads to bed. [20:52:04] gnite everyoe [20:52:07] *everyone [20:52:46] jdlrobson: I would just write "Save" in English, too. [20:53:19] Maryana: matt is saying the banner should now be targeted only to android [20:53:31] sweet [20:53:55] aharoni: no problemo poke me after the deployment and i'll change it (unless you want to change it in translate wiki now) [20:54:13] English strings can only be changed in the code. [20:54:44] brion: tfinc off to sleep. Want anything from me before I leave? [20:55:02] awjr: MaxSem looks good to me - i've tested all i can [20:55:17] Maryana, do you concur? ^ [20:55:28] jdlrobson: the banner request URL is still pointing to HTTP :( [20:55:36] that should be protocol relative, using whatever the user is currently on [20:55:56] since we're targeting this to android users, this is giong to cause problems for folks logged in using chrome [20:56:10] also awjr/ jcmish the commit logs are not consistent with the summaries [20:56:12] YuviPanda: were good [20:56:28] actually maybe they are..1s [20:56:29] jdlrobson: for instance, i get a warning: [20:56:29] The page at https://test.m.wikipedia.org/wiki/Page009 ran insecure content from http://test.m.wikipedia.org/wiki/Special:BannerRandom?userlang=en&sitename=Wikipedia&project=test&anonymous=false&bucket=1&country=US&device=android&slot=3. [20:56:37] are we sending folks to the desktop play store view? [20:56:51] YuviPanda: i'm good. catch you tomorrow [20:56:55] Maryana: are you using a mobile phone? [20:56:57] when it was showing on my iphone, it took me to desktop. not terrible, but not optimal if there's a mobile view [20:57:07] yeah, i was using my iphone [20:57:08] brion: tfinc gnite. [20:57:14] mmm, the mix of secure and insecure is no bueno [20:57:15] everyone else too :) [20:57:16] night [20:57:16] Maryana: so yeh usually this goes to the native google play app [20:57:17] i haven't checked it on android [20:57:18] that's normal [20:57:24] ok [20:57:25] thanks for the treollo run through [20:57:26] MaxSem: that sounds like a CentralNotice bug [20:57:29] just checking [20:57:31] yeah [20:57:38] tfinc: glad to help [20:57:43] looks like we're logging "what does this mean" clicks properly, jdlrobson :) [20:57:44] and we can't enable banners until it's fixed [20:58:13] MaxSem: awjr i'm also not convinced this will behave the same on live wiki [20:58:30] how so? [20:58:30] test wiki works differently to live [20:58:32] jdlrobson: why would it behave differently? [20:58:34] live queries meta wiki [20:58:38] test queries test [20:58:53] another example of how test wiki is not very useful for testing :) [20:58:57] hmm, ok - let's give it a shot [20:59:14] *waves* [20:59:16] but I'll revert if it doesn't work [20:59:18] whats up mwalker [20:59:20] MaxSem: so i'm loving at live wiki right now [20:59:23] and it seems to query https [20:59:25] hi mwalker! [20:59:32] https://meta.wikimedia.org/wiki/Special:BannerRandom?userlang=en&sitename=Wikipedia&project=wikipedia&anonymous=true&bucket=1&country=US&device=&slot=16 [20:59:39] jdlrobson, I didn't deploy that change yet [20:59:40] mwalker when a user logs in to a WMF property on mobile, they are forced to use https [20:59:45] MaxSem: it doesn't matter [20:59:50] MaxSem: it's live :) [20:59:52] it's just silent [20:59:57] but right now, on testwiki, CN is pulling banners from http even when a user is logged in using https [21:00:03] it dies silently without the div which that config change introduces [21:00:14] which can cause an insecure content warning/or have the content totally blocked [21:00:17] GhostNotice [21:00:31] mwalker: will that be a problem in production as well? the request URI should really be proto-relative [21:00:44] Maryana, are we good to deploy? [21:00:45] awjr: I'm not sure what's causing it -- if you take a look at the code that's running it -- it's using a protocol relative URL [21:00:57] everything looks good to me, maxsem [21:00:58] funny [21:01:06] as long as this banner thing works [21:01:08] :) [21:01:08] ok, fingers crossed it Just Works in prod then, i guess [21:01:11] awjr: i'm 90% sure this will not be a problem on live [21:01:23] if it is, what's our exit strategy? [21:01:24] i like your optimism, jdlrobson :) [21:01:29] Maryana: revert the config change [21:01:40] shouldn't be a big deal [21:01:45] ok [21:01:47] awjr: i don't think you understand.. [21:01:52] well, i'm game if you all are [21:02:03] this config change only adds a div to the html [21:02:11] i dont think i do either jdlrobson, which is why im concerned about it :) [21:02:12] we are already querying meta for banners [21:02:30] oh, and the requests are using https when the user is using https? [21:02:34] yes correct [21:02:43] cool [21:02:47] so in theory since we are not redeploying central notice it shouldn't switch to http [21:02:55] it seems really weird that it's not doing that on testwiki [21:03:01] it's not weird [21:03:16] it is if it's supposed to be protocol relative like mwalker said [21:03:17] testwiki queries itself for banners so obviously uses a different code path which seems to ignore the protocol [21:03:33] there must be a bug in there somewhere [21:03:33] by the way, scap isn't needed today [21:03:50] wow [21:03:53] awjr: it's also worth pointing out that the banners won't show on all pages at first - as they will not show on cached pages [21:04:34] jdlrobson: since we're only displaying banners to logged in users, there will be no cached pages [21:04:43] we don't cache for logged in users [21:04:44] awjr: you are correct [21:04:51] i forgot this [21:05:15] so, looking at CommonSettings.php, mwalker is correct - it should be using proto-relative URLs even for testwiki [21:06:37] done on 1.22wmf2 wikis [21:06:44] awjrichards@fenari:/home/wikipedia/common/wmf-config$ grep -r wgCentralBannerDispatcher * [21:06:44] CommonSettings.php: $wgCentralBannerDispatcher = "//test.wikipedia.org/wiki/Special:BannerRandom"; [21:07:29] btw, enwiki = 1.22wmf2 wiki [21:08:01] * jdlrobson shrugs [21:08:49] yeah jdlrobson, idk, the behavior seems a little concerning to me though given the configuration. i'll file a bug [21:09:01] awjr: yeh very weird [21:12:35] whoa what is doubly weird is that on desktop testwiki, Special:BannerRandom uses https [21:13:11] awjr: I know!! [21:13:25] I don't understand what it's doing! [21:13:27] so jdlrobson tells me we can't actually see the banner until we enable the campaign [21:13:37] Maryana: yep -- that's true [21:13:38] oh, and what is trebly weird is that it uses https on testwiki… at least when it's not displaying a banner... [21:13:44] jgonera: i'm fine with the task as is. do you have any other changes that you want to get in before we start using it ? [21:13:50] trebly. heh. [21:13:51] Maryana: also, the config change needs to be synced out to the cluster [21:14:08] Maryana: if you don't want to enable it on enwiki; aawikibooks is a good test platform [21:14:20] (because aawikibooks is a closed wiki) [21:14:21] what language is aa?? [21:14:25] aafrikans? [21:14:34] tfinc, not as of now, I might have some small fixes tomorrow after I try writing the solution myself [21:14:40] i'm ok with enwiki [21:14:42] k [21:14:42] wp:bold [21:14:46] Maryana: I think aa => Afar [21:15:59] all right, everything's deployed [21:16:57] this thing with CN is really weird, the request URL (that i see in chrome developer tools) is using https… but i still get the warning for running insecure content from http.... [21:17:11] i moved the nearby & translatewiki cards back to in dev, since we noticed some outstanding weirdness on the former and we didn't complete the latter, per aharoni [21:17:38] MaxSem: production? [21:17:44] i'm not sure how to test this guy: https://mingle.corp.wikimedia.org/projects/mobile/cards/461 [21:17:58] jcmish, yes [21:18:01] all that leaves is the banner [21:18:05] by the way tfinc - I tried DolphinBrowser in Dolphin Browser and it doesn't work:P [21:18:12] FAIL [21:18:16] it did before [21:18:35] MaxSem: we should revert that config change [21:18:45] jdlrobson, mwalker, Maryana: the insecure content problem is present in production too [21:18:50] tfinc, it simply doesn't retrieve any wiki content - no main page, no search [21:18:50] bah [21:18:56] awjr, on it [21:19:08] awjr: i'm not seeing that problem.. [21:19:29] MaxSem, is there any chance of getting https://gerrit.wikimedia.org/r/60512 pushed out to production? ori-l and i were chatting about this, and he was wondering if it can be squeezed in here. [21:20:26] awjr: where are you seeing insecure content problem? [21:20:39] http://i.imgur.com/RNerstB.png [21:20:41] jdlrobson: ^ [21:20:43] awjr: which link [21:21:00] oh i'm not seeing that but that's a different problem awjr [21:21:02] see screenshot above, jdlrobson [21:21:24] dr0ptp4kt, did Ori review it? [21:21:44] yes, although i'll ask him now if he will formally stamp it. [21:21:51] awjr: what's the content of that file? [21:22:03] which file jdlrobson? [21:22:09] the one you've highlighted [21:22:12] i want to know the response [21:22:17] oh [21:22:30] derp one sec [21:22:46] but awjr it's requesting from https [21:22:52] i suspect something in the content is begin blocked [21:23:29] maybe cross domain JSONP calls are now blocked by chrome? [21:23:51] but the URI it says it's blockoing is http [21:24:01] awjr: that's why i want to see the url :) [21:24:02] mhurd: seems like you need the 4S on a pretty regular basis. i'm going to order an ipod touch to back us up [21:24:08] er [21:24:13] jdlrobson: i am getting this: insertBanner( false /* due to internal exception */ ); [21:24:20] the url is https://meta.m.wikimedia.org/wiki/Special:BannerRandom?userlang=en&sitename=Wikipedia&project=wikipedia&anonymous=false&bucket=1&country=US&device=&slot=20 [21:24:42] actually, the URL is http://meta.m.wikimedia.org/wiki/Special:BannerRandom?userlang=en&sitename=Wikipedia&project=wikipedia&anonymous=false&bucket=0&country=US&device=&slot=24 [21:24:51] i got autoredirected to https when i clicked it [21:24:58] YuviPanda: we [21:25:00] oh [21:25:11] awjr: i don't get that warning which is weird [21:25:24] me neither jdlrobson :( [21:25:27] well we want fancy graphs for Commons as a whole. MORE STATS. [21:25:32] no awjr .. i don't actually get it [21:25:34] at all :) [21:25:35] is it possible the banner content is requesting insecure content? [21:25:47] what version of chrome are you running? [21:26:00] OH [21:26:04] mwalker: http://stackoverflow.com/questions/12216208/chrome-now-blocking-all-jsonp-requests-from-https-to-http [21:26:06] i wonder if it's because im in porn mode [21:26:25] jdlrobson: I know! but the original request is being made to HTTPS! [21:26:31] tfinc: do they still make 3.5 inch touches? [21:26:32] it's the only case it should run.. so yeh this is odd [21:26:36] when someone says to me "OTHERSHITEXISTS why is thing here?" i can say "well nobody noticed it among the 1298261 files which were uploaded since then" [21:26:37] awjr: yeh that will be the reason [21:26:42] awjr: of course it will do that [21:26:53] mhurd: you mean these http://store.apple.com/us/browse/home/shop_ipod/family/ipod_touch_4thgeneration ? [21:27:04] now this makes more sense [21:27:08] awjr: that's not a bug that's expected :) [21:27:09] tfinc: nice! [21:27:15] New patchset: JGonera; "Fix header styling" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60579 [21:27:18] mhurd: would you rather i get that ? [21:27:31] i dont understand why it would behave like that in incognito [21:27:54] also, im seeing js errors in beta on production [21:28:08] awjr: well the whole point in incognito is to keep things private [21:28:24] communicating with an external site without your consent would be something that could leak your privacy [21:28:41] although that said i cannot replicate on my incognito mode [21:28:46] New patchset: JGonera; "Fix header styling" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60579 [21:29:01] jdlrobson: im using Version 26.0.1410.65 [21:29:13] awjr: same as me [21:29:30] awjr: what js errors are you seeing - this concerns me more [21:29:54] they seem to have gone away, actually, mightve been using cached resources [21:30:06] awjr: still not able to replicate insecure content problem [21:30:13] jdlrobson: you're on testwiki? [21:30:18] awjr: no on en wiki [21:30:27] searching on non beta and beta on prodcuttion looks good [21:30:48] jdlrobson: max disabled CN on enwiki for mobile [21:30:48] New patchset: JGonera; "Fix header styling" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60579 [21:30:55] awjr: why?! [21:31:00] it's working fine.. [21:31:01] the config was reverted [21:31:10] i asked him to, since i was seeing the issue [21:31:25] it's trivial to flip it back on [21:31:39] did this behavior you saw happen outside incognito mode? [21:32:35] awjr: [21:32:55] acutally, yes it does it jdlrobson [21:33:18] it does or it did? [21:33:32] and to be clear what exactly does it do - throw the unsecured content error? [21:33:38] can you see if that effects desktop too [21:33:44] (under same protocol) [21:33:46] i hadn't checked before outside of incognito; i generally test in incognito so i don't have to clear all of my cookies [21:34:01] so, it does. [21:34:03] lemme check desktop [21:34:08] * jdlrobson very confused [21:34:21] jdlrobson: it does exactly what i said it does before, give me this error: [21:34:22] [blocked] The page at https://test.m.wikipedia.org/w/index.php?title=Main_Page&welcome=yes ran insecure content from http://test.m.wikipedia.org/wiki/Special:BannerRandom?userlang=en&sitename=Wikipedia&project=test&anonymous=false&bucket=0&country=US&device=android&slot=24. [21:34:27] awjr: but you are on test [21:34:35] yes... [21:34:47] did you see this on enwiki [21:34:50] yes [21:34:52] inside and outside incognito mode? [21:35:00] i did not check outside of incognito mode [21:35:29] but based on what im seeing now and what we saw before, i do not expect it will be any different [21:36:25] awjr: I have no clue how to use Chrome's javascript debugger -- but can you confirm this issue exists in debug mode -- and then breakpoint at the point we make the jsonp call to verify that the uri outbound is HTTPS? [21:36:38] (debug mode --> ?debug=true) [21:37:12] mwalker: i can confirm it happens with debug=true [21:37:15] where does the jsonp call happen? [21:37:25] so currently i am not seeing this insecure content warning on test wiki or test wiki in incognito mode so i don't know what to say [21:37:40] on line 76 of bannerController.js [21:37:47] MaxSem, ori-l code reviewed https://gerrit.wikimedia.org/r/60512 [21:37:59] ^ and put his stamp of approval on it in gerrit [21:38:10] awjr: it's the last bit of loadRandomBanner() [21:38:42] so awjr jgonera also doesn't have this issue [21:38:44] i suspect it could be one of your browser settings [21:39:06] mwalker: are you seeing this issue? [21:39:16] no; but that doesn't mean it's not a valid problem [21:39:21] Maryana: are you seeing this issue? [21:39:45] i'm not disputing it's a valid problem - i'm just disputing that it seems to be an edge case [21:39:53] awjr: can you replicate it in another browser? [21:40:08] and also awjr is it actually throwing any visible error/stopping you viewing the site? [21:41:00] jdlrobson: one sec, one thing at a time - it is throwing a visible warning, it is not stopping me from viewing the site, but it is not displaying the banner [21:41:02] dr0ptp4kt, deployed [21:41:14] MaxSem, thanks! [21:41:17] note that this problem doesn't seem to happen when the banner shouldn't be displayed [21:41:42] awjr: you told me that it said insertBanner false though [21:41:51] so it's not going to show a banner.. [21:42:03] chrome is just informing you it blocked code [21:42:09] this could be a chrome extension, it could be a chrome setting [21:42:23] jdlrobson: i think that was because i opened it in a tab that was not masquerading as an android device; one sec [21:42:23] it could have been mistaken for an ad [21:42:48] so awjr you missed out some key information [21:42:55] the fact you are overriding the user agent is also significant [21:44:18] mwalker so the breakpoint on line 76 of bannerController.js shows it's using a proto relative URL [21:44:25] "//test.wikipedia.org/wiki/Special:BannerRandom?userlang=en&sitename=Wikipedia&project=test&anonymous=false&bucket=0&country=US&device=desktop&slot=6" [21:47:17] so jdlrobson, i also don't see the banner showing up for me on my galaxy nexus in chrome. brb while i grab my cord to remote debug [21:47:26] MaxSem, i confirmed the user security groups went into effect in meta-wiki. thx again [21:48:08] dr0ptp4kt, could you create https://meta.wikimedia.org/w/index.php?title=Meta:Zeroadmin&action=edit&redlink=1 too please? [21:48:56] including info about what it's for, who has access etc [21:48:57] Thehelpfulone, ah right, thanks! yes, will do [21:49:02] no problem :) [21:49:35] http://support.google.com/chrome/bin/answer.py?hl=en&answer=1342714 [21:49:49] mwalker awjr: i suspect that there is something wrong with the https certificates [21:50:08] also, did you intend to make it so that crats can't add people to that group? [21:51:05] On Android 4.2 and newer, Developer options is hidden by default. To make it available, go to Settings > About phone and tap Build number seven times. Return to the previous screen to find Developer options. [21:51:06] wtf [21:51:17] that is the silliest thing i've ever heard [21:51:25] awjr: yup. welcome to the club [21:51:39] awjr: thats what yuvi said to me last week when i had to do the same [21:51:49] zz_YuviPanda: --^ [21:51:50] :p [21:52:02] awjr: mwalker so actually it's nothing to do with the url [21:52:03] hehehe yeah, i just got an OTA upgrade to 4.2 [21:52:05] run insertBanner( false ) [21:52:12] it causes the exception regardless [21:52:15] * jdlrobson looks at insertBanner( false ) code [21:53:44] so it's record impression thats the problem mwalker [21:54:14] that's also protocol independent though! [21:54:38] mwalker can we configure the banner on testwiki to *always* display? debugging this with constantly having to clear cookies etc is tough [21:55:06] mwalker: http://meta.m.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&country=US&userlang=en&project=wikipedia&db=enwiki&bucket=1&anonymous=false&device= [21:55:06] jdlrobson: oh... maybe it's because that variable is not actually defined :p [21:55:36] mwalker: it redirects that's why [21:55:37] awjr: it should always display... what cookies are you having to clear? [21:55:44] https://meta.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&country=US&userlang=en&project=wikipedia&db=enwiki&bucket=1&anonymous=false&device= redirects to http [21:55:49] there's your problem [21:55:51] *facepalm* [21:56:04] jumping to tech to pester people there [21:56:09] 302 Moved Temporarily [21:56:20] oh i thought it was configured to only display once for logged in users [21:56:38] never mind -- chrismcmahon and hashar are away [21:56:52] awjr: no need to clear cookies unless you close it [21:57:47] anyway i don't see this as a reason to disable central notice on mobile.. [21:57:55] it's happening anyway after all [21:58:04] and has probably been happening for the last week [21:59:08] allowing for mixed content is a security concern [22:00:13] jdlrobson: where are you seeing that redirect? I don't get it on meta.m or meta.beta [22:00:15] awjr: this is happening on en wiki regardless of the config variable [22:00:26] that is not good [22:00:34] that does not mean we should enable it for mobile [22:00:41] mwalker: $( '' ).attr( 'src', 'https://meta.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&country=US&userlang=en&project=wikipedia&db=enwiki&bucket=1&anonymous=false&device=' ) [22:01:10] I get a 200 OK with that URL [22:01:15] in chrome mwalker ? [22:01:20] i get a 302 [22:01:33] i got a 200 as well [22:01:43] you need to override device [22:02:16] i'm using Android 4.0.2 [22:02:19] in chrome -- device as several things -- still getting 200's [22:02:32] jdlrobson: I'm coming down [22:02:47] jdlrobson: yeah im using android 4.0.2, but still getting 200 [22:03:01] awjr mwalker are you looking at the network tab? [22:03:08] yes [22:03:10] it will result in a 200 [22:03:13] but it will do a redirect [22:03:19] the important thing is the 200 is http [22:03:21] not https [22:03:48] that is not the behavior im seeing [22:04:19] we seem to be having crossed wires, jdlrobson :p [22:05:47] and for some reason i cant get adb to recognize my device anymore :-/ [22:08:49] New review: MaxSem; "Brion, the problem here is in possibly parsing _talk page_ along with subject page." [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60093 [22:10:44] awjr: i've managed to replicate it with mwalker [22:10:55] so as i said before it has nothing to do with the config variable so i would redeploy that if i was you [22:11:05] it seems silly not to [22:11:07] that makes me feel less crazy jdlrobson [22:11:20] it looks like a redirector problem [22:11:24] on certain urls [22:14:15] jdlrobson: i dont see the problem with CN disabled on MF [22:15:20] so the problem is this [22:15:32] CentralNotice makes a request to https://meta.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&counntry=US&userlang=en&project=wikipedia&db=enwiki&bucket=1&anonymous=false&device=iphone [22:15:41] the redirector kicks in and redirects to the meta.m domain [22:15:45] and seems to be stripping the https [22:15:52] i suspect because the cookie is not set there [22:16:11] or there is something funky in the redirector [22:16:12] redirector always strips the https actually [22:16:22] https://meta.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&counntry=US&userlang=en&project=wikipedia&db=enwiki&bucket=1&anonymous=false&device=iphone redirects to http://meta.m.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&counntry=US&userlang=en&project=wikipedia&db=enwiki&bucket=1&anonymous=false&device=iphone [22:16:33] so this is the bug here. nothing to do with CentralNotice or MobileFrontend [22:16:47] New patchset: JGonera; "Fix styling of Nearby" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60592 [22:17:44] so awjr can we push configuration changes that effect en.m.wiki but not en.wiki? [22:17:51] ok that makes sense jdlrobson, though it does have to do with CN - for mobile requests CN should be using the .m domain [22:18:18] jdlrobson: does that problem only exist when a banner is actually enabled? [22:18:43] awjr: no -- we make the recordimpression call regardless of if there's a banner or not [22:18:58] awjr: this is a problem with the redirector actually - an https url should not redirect to http [22:19:02] why do i not see the problem all the time then? [22:19:20] awjr: you need to be a mobile device - i'm seeing it consistently [22:19:26] on en.wiki [22:19:34] (right now) [22:19:41] jdlrobson: this has been an open issue with ops and there's an open bug about it, but we can't support https urls in the mobile redirector for performance reasons [22:19:43] so one quick fix would be to to set $wgCentralBannerRecorder' to "//meta.m.wikimedia.org/wiki/Special:RecordImpression" for mobile only [22:19:56] i'm not sure if we can do config changes that only effect mobile [22:20:46] so it's preferable to not rely on the redirector and access .m domains directly [22:20:46] awjr; that's a massive privacy hole!! [22:22:14] New patchset: JGonera; "Add a jshint exception in mf-oop.js" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60594 [22:22:18] awjr: i still think this is silly and a problem that needs to be solved but that aside in the meantime can we override the config variable ? [22:22:44] brion: very cool https://github.com/wikimedia/Commons-iOS/pulse [22:22:49] i think that makes sense jdlrobson - MaxSem ^^ [22:23:16] awjr: so to be clear we can set $wgCentralBannerRecorder = "//meta.m.wikimedia.org/wiki/Special:RecordImpression"; for Mobile only? [22:23:21] ie. don't apply this config change to desktop [22:23:33] woo things to review :) [22:23:55] we can [22:23:57] maybe jdlrobson, but it depends on the order of things... [22:24:00] EnterobileMode [22:24:06] EnterMobileMode [22:24:11] oh yeah, i forgot you added that hook [22:25:22] mwalker: what is the vector you see? [22:26:34] mwalker:https://bugzilla.wikimedia.org/show_bug.cgi?id=35215 [22:27:39] awjr: mostly just MITM stuff -- carrier could inject things into the stream/see what articles you're viewing [22:27:43] it's very unexpected as well [22:28:28] New patchset: Jdlrobson; "Add a jshint exception in mf-oop.js" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60594 [22:28:35] Change merged: Jdlrobson; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60594 [22:31:04] yeah - both are true. if you're really concerned, you can directly access https://en.m.wikipedia.org - or log in, which will force https. but.. the theory was iirc that when we move away from using squid proxy for desktop, we can have it fixed. feel free to add your thoughts/concerns to the bugzilla ticket [22:32:54] awjr, jdlrobson: https://gerrit.wikimedia.org/r/60597 [22:34:00] MaxSem: looks good to me [22:34:13] * awjr looking [22:35:21] what about $wgCentralHost [22:35:44] well currently only thing effected is mw.config.set( 'wgCentralBannerRecorder', "//meta.m.wikimedia.org/wiki/Special:RecordImpression" ) [22:35:54] so even this might be overzealous [22:37:03] i dont really know how those get used in CentralNotice, but looks OK - might be good to have mwalker confirm [22:37:05] awjr, amended [22:37:35] MaxSem php -l erro [22:37:35] r [22:37:54] at least according to jenkins [22:38:24] arg [22:38:54] mwalker: can you dbl check this? https://gerrit.wikimedia.org/r/#/c/60597/2 [22:40:51] MaxSem: awjr are you also enabling the variable to enable CentralNotice div? [22:41:37] revert the revert [22:47:48] MaxSem: looks like mwalker +1'd the change, i think it's good to go [22:48:27] would the mobile formatter negatively impact any output coming from CN if we're using meta.m for all the reqeusts? [22:49:34] if it's just a div, it shouldn't [22:49:55] we should stop transforming special pages, btw [22:50:58] hmm, nice - by going through MobileFormatter, we take users' don't show images preference into account [22:51:31] Bannnnnnnnnnnnnnnnnnnnnner. [22:52:30] New patchset: JGonera; "Handle all the Node.js dependencies the same way" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60601 [22:57:51] MaxSem: are we good to push out thos config changes? [22:58:04] see #-ops [23:06:49] deployed [23:09:28] New patchset: Jdlrobson; "Story 436: Use file name for images with descriptions with templates" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/56613 [23:10:38] awjr, jdlrobson^^ [23:11:07] cool MaxSem, im not seeing the same blocked content issue anymore, but the Special:RecordImpression URL doesn't seem to be pointing at meta.m - rather https://meta.wikimedia.org/wiki/Special:RecordImpression?result=hide&reason=empty&country=US&userlang=en&project=wikipedia&db=enwiki&bucket=0&anonymous=false&device= [23:11:22] MaxSem: awjr yeh i'm still seeing old confi variable on en wiki [23:11:33] dafuq? [23:12:02] Thehelpfulone, https://meta.wikimedia.org/wiki/Meta:Zeroadmin has been created. regarding assignment of rights for bureaucrats, would you please clarify? bureaucrats get userrights by default; is there some switch that looks amiss? [23:12:50] hang on.. when do config variables get added to the page [23:12:58] before or after EnterMobileMode [23:13:22] should be before right? [23:14:40] * jdlrobson doesn't know enough about site configuration to understand why the config isn't applying.. [23:15:32] jdlrobson: what do you mean by 'get added to the page'? [23:16:11] dr0ptp4kt, thanks, I meant bureaucrats being able to assign the rights to other people [23:16:24] oh, i see what you're saying - this is what i was mentioning earlier. the config vars can be overriden after they're set, so long as they're overridden before they're used [23:16:26] so staff request crats give them the access [23:16:29] onResourceLoaderGetConfigVars hook adds variables that get sent to RL [23:16:48] so as long as those centralnotice config vars don't get used before that hook is invoked, it should be fine, but i dont know the order of these things [23:17:20] oh MaxSem, variable scope [23:17:28] in your anonymous function [23:17:33] * MaxSem rofls [23:17:58] * awjr facepalm [23:18:03] should've noticed that in CR [23:18:23] whoops [23:18:53] Thehelpfulone, $wgAddGroups and $wgRemoveGroups is what you refer to, correct? i see those are arrays and not booleans for meta-wiki. lemme check on permissions assignment there. thanks! [23:20:44] dr0ptp4kt, yes, you'll see that crats can add/remove other groups like central notice [23:20:47] central notice admin* [23:21:08] awjr, we should llok again, maybe there's something else equally stupid [23:22:39] yeah MaxSem [23:25:18] https://gerrit.wikimedia.org/r/#/c/60607/ [23:25:20] MaxSem: it otherwise looks OK to me [23:25:40] yeah, that lgtm [23:26:40] -ops is for Wikimedia IRC ops. [23:31:44] awjr, deployed [23:34:26] i don't think this is going to work [23:34:29] i just tested locally.. [23:34:41] i stand corrected [23:34:47] it seems to work :) [23:35:33] good work MaxSem [23:37:09] mwalker: can we activate this campaign then? [23:37:22] one moment [23:38:02] jdlrobson: live [23:38:10] it might take up to 15 minutes for cache to clear [23:41:08] awjr, when you have a moment, can you check if https://gerrit.wikimedia.org/r/#/c/60601/ works for you? [23:44:43] bad news mwalker awjr MaxSem ... [23:44:44] New patchset: Jdlrobson; "SiteNotice html fail" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/60609 [23:45:29] uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuhhhhhhhhhhhhhhhhhhhhhh [23:45:51] gross [23:45:58] how did we miss that [23:46:07] * jdlrobson does a facepalm [23:46:32] I'm already too sleepy to deploy [23:46:35] i also have to go soon :/ [23:46:56] I can stay and watch this [23:48:18] i've tried various devices and not seen too many issues so hopefully it's not too damaging [23:49:21] another reason for https://bugzilla.wikimedia.org/show_bug.cgi?id=31876 [23:52:37] derp [23:52:54] i can get that out so long as no one else is deploying [23:52:57] that seems… urgent. [23:53:07] jdlrobson, mwalker ^ [23:53:17] MaxSem: ^^ [23:53:47] awjr: I'd vote to push it -- it doesn't seem to be causing rendering issues on my phone; but... [23:54:04] well the other option is to disable mobile site notice and deal with it later [23:54:17] but, i'll be around for at least another hour so i dont mind trying to get this out [23:54:23] awjr: i also have to go :( [23:54:32] awjr: i say disable site notice [23:54:36] ah [23:54:39] there seems to be an issue with device not being set anyway. [23:54:40] yeah, in that case... [23:54:54] wgMobileDeviceName is set to empty string for me [23:54:59] okidoke, let's revert the revert of the revert [23:55:05] i think the mobile device detection module isn't working properly now for whatever reason [23:55:14] jdlrobson: do we have bugs open? [23:56:55] awjr: no; jdl didn't create a bug [23:58:39] all we've got right now is that mw.config.get( 'wgMobileDeviceName', 'desktop' ) returns "" when spoofing a android UA on chrome [23:58:59] sigh [23:59:08] it worked. at one point [23:59:16] i know! [23:59:37] we need moar tests!