[09:24:16] good morning y'all [09:54:29] morning [11:39:53] morning :) [11:47:50] good morning d3r1ck [12:40:00] off to walk dog [12:50:49] jdlrobson: btw, every once in a while i run into your World of Wikipedia map and I have to smile. thx [14:13:09] Anyone knows which channel Siebrand is usually on? And what is his nick? [14:26:31] not sure if he's usually on IRC [14:26:40] if anywhere it would be #mediawiki-i18n [14:46:23] Krenair: thanks [16:10:53] bmansurov any suggestions regarding https://gerrit.wikimedia.org/r/#/c/268185/15/resources/mobile.toggle/toggle.js ? [16:10:58] oops, not online [16:17:20] mdholloway: hey, i'm trying to test https://gerrit.wikimedia.org/r/269425 but i'm not getting any W0 notifications in the app (I added my IP to the test portal). Is this supposed to work yet, or is there something else on the server end that needs to be done? [16:19:09] dbrant: sorry, you won't see notifications from that patch alone. the patches are kind of interconnected in nonobvious ways. one sec, let me take a look back. [17:36:31] bmansurov: hey, I have a hard time visualizing how to test viewport-based functions without a screen, not to mention I'm not the most familiar with qunit. Want to pair on some tests after standup? [17:37:08] jhobs: we could, but we should test the underlying functionality, the rectangle part [17:38:07] bmansurov: right, but the element has to be on a page to test it against the rectangle, doesn't it? [17:38:23] jhobs: no i think [17:38:32] jhobs: let's pair [17:38:51] bmansurov: wait yeah I can just make it an object with the offset method [17:38:58] yep [17:39:00] but yeah let's pair after standup [17:39:05] ok [17:39:10] I'll write some stuff up before then [17:39:15] cool [17:44:02] mdholloway We also need a patch to update WikipediaZeroHandler#hostSupportsZeroHeaders. Do we have Phab tasks for the W0 work? [17:45:35] bearND: that's actually coming out in https://gerrit.wikimedia.org/r/#/c/269548/ (which as i mentioned to dbrant in a pm is the patch where zero banner behavior is actually restored) [17:45:55] bearND: RESTBase just passes along the headers. i don't think a change is needed to special-case it. [17:46:49] mdholloway: yes, i don't see a need to special case it [17:47:47] bearND: this is the main tracking task for W0 work on android: https://phabricator.wikimedia.org/T119126 [17:49:40] mdholloway: ah, i see. By look ing at the title I thought this was a new feature and not fixing the old W0 behavior. [17:50:39] bearND: yeah, it is. there's no phab task currently for fixing the old behavior; it kind of just got lumped in. i can create a separate task if you'd like. [17:51:22] has disturbed's "believe" aged well? let's find out… [17:53:08] mdholloway, bearND: is this about forwarding the Varnish request headers to the content service? [17:53:21] gwicke: yes [17:53:37] do you plan to vary your response based on those headers? [17:54:26] gwicke: no, we just rely on their presence to know whether to display native Wikipedia Zero notifications to the user [17:55:33] gwicke: i don't think we need to change the content service for that. This all happens on the Varnish level. So, the changes we're discussing here are for the app itself; to use the new X-Carrier(-Meta) headers and to check also the non-mdot domains for them. [17:55:51] okay, so you are looking at response headers in the app [17:55:57] yes [17:56:20] okay; in that case, RB shouldn't need to care, really [17:56:42] gwicke: right. i don't think any change is needed. [17:56:59] Varnish will add those response headers no matter what RB / content service are doing [17:57:17] kk, thanks for humoring me ;) [17:58:04] np, thanks for checking! :) [18:05:03] niedzielski: hey, are you still planning to work on this one: https://phabricator.wikimedia.org/T104491 If you like, I can pick it up? [18:05:56] dbrant: there's a patch that's waiting for design feedback. the latest screenshots are at the bottom [18:06:10] niedzielski: aha, i see [18:16:51] mbinder: standup? [18:29:08] FlorianSW: reckon we can get https://gerrit.wikimedia.org/r/#/c/261202/20 merged? I will take a look at the config change right away given you are around :) [18:29:39] jdlrobson: I'll take a look :) [18:29:50] hi jhobs. do you know which task I should update with the specifics of the "array" for the reader survey? [18:30:09] bearND, dbrant around? (or some other android mobile app member?) [18:30:24] FlorianSW: always [18:30:52] FlorianSW: about wgMFUserBlockInfo [18:31:08] dbrant: I expected that :P :D Is there a restriction in the length of characters I can copy from the Wikipedia app? [18:31:09] given it is in the mobile.user module which can be loaded on desktop surely it should be on all skins? [18:31:22] it's also in Page which again can be used outside mobile skin [18:31:41] FlorianSW: hi [18:32:38] FlorianSW: there is, in the current production version, but not in the latest beta. [18:32:53] jdlrobson: I think the question is: is the config really _used_ or not (and as far as I know, the mobile modules _can_ but aren't be loaded on desktop skins, right?) :/ [18:33:10] not quite true [18:33:20] Gather loads the code in desktop mode [18:33:28] dbrant: ah, ok :) Interesting. Does this have a technical background or was it a bug (is it tracked in phabricator)? [18:33:37] jdlrobson: oh, ok, then ignore the comment :) [18:33:38] although wgMFBlocked is not used now it could be [18:33:47] alternative would be to move it into skins.minerva.editor.scripts [18:33:51] and then only serve it to Minerva [18:33:53] what do you reckon? [18:34:18] FlorianSW: more of a bug, really. [18:34:36] also with respect to the extension.json callback - will that honour any config options in LocalSettings.php if I do that (I assume you mean onExtensionSetup? [18:34:56] dbrant: ah, ok, thanks :) [18:36:10] jdlrobson: I don't think that we need to add a config variable to desktop sites, if it's currently only used in mobile, that's unnecessary overhead :) So, if you want to invest some time to rework the code and move the usage to a "minerva only", I would strongly prefer that :) [18:37:55] jdlrobson: yep, it should (I think you mean the callnbacks, where you can define a callback like onExtensionSetup (or any other name, if you want)). callbacks are executed right after the extension.json is processed, which is triggered after LocalSettings.php is loaded. [18:38:35] okay let me have a look [18:40:43] dbrant: one question left: Do you know, when the neyt prod release is planned? (Wasn't there a roadmap/deployment plan somewhere? :/) [18:44:02] FlorianSW: was curious if you were planning to go to the hackathon in Israel. Working off the community wishlist seems exciting - quite happy to see a focused hackathon! [18:44:26] phuedx: did a bug get raised for the broken editor [18:44:34] jdlrobson: sec [18:45:14] jdlrobson: I requested a scholarship, yes :P And iirc the decision will be made in this week :] And if I get one, sure, I'll be there :D (Hopefully, if I get vacation, but that's probably a smaller problem) :) [18:45:16] leila: ummm which survey again? [18:45:24] jdlrobson: Are you there, too? [18:45:45] leila: is it this one? https://phabricator.wikimedia.org/T125946 [18:46:46] leila: if so, then just add it to the description and/or as a comment on that task [18:47:44] FlorianSW: we're hoping to release another beta today, and production next week. [18:47:58] dbrant: +1! :) thanks [18:51:33] FlorianSW: i'm hoping so but we'll see if i get allowed to go :) [18:51:47] would be awesome to catch up [18:52:05] I saw some very interesting wishes on the list :) [18:52:06] FlorianSW: i pushed some new patches. They look much saner. [18:52:30] whoopppss forgot to include one of my changes [18:53:36] jdlrobson: you'll need to remove the untitled.txt :) [18:53:48] https://gerrit.wikimedia.org/r/#/c/268333/10/includes/untitled.txt,unified [18:53:55] hah [18:54:28] FlorianSW: i pinged nirzar and jon katz about your menu patch [18:54:35] i think it's an interesting idea worth exploring [18:55:03] also minor change if you want to merge phuedx or FlorianSW - i noticed it on my travels > https://gerrit.wikimedia.org/r/#/c/268334/ [18:55:15] jdlrobson: thanks :) It's currently just a fragile change which needs some more work, but I think to show the way it could be it's enough. Let#s see what they say :) [18:56:01] d3r1ck: how did you get on yesterday? [18:56:16] jdlrobson: ah, I reviewed the change already and wanted to check, why we made this, could you find it out? [18:56:49] FlorianSW: i suspect it was moving last modified bar from top to bottom (beta->stable) but i can check [18:57:41] jdlrobson: would be great, or I can do, I just want to be sure :) [18:57:41] FlorianSW: looks like kaldari added them both [18:57:47] in one change? :P [18:57:54] I0874956d593c02bea38d45eafebbba781dc5ab9a and then Ib7934cd1bd408b048c7a0f892631d27d588f187a [18:58:14] within 5 months of each other [18:58:20] i think it was just a typo from the start [18:58:53] seems so :) [18:58:57] thanks for checking! [18:59:55] bmansurov_break: when you get back could you take a look at the patches for https://phabricator.wikimedia.org/T124992 - given the upstreaming we've done so far i'm keen to wrap that up [19:00:13] (your use of it in the language switcher patch reminded me the dangers of not finishing that up) [19:01:51] jdlrobson: well, i feel asleep after eating, i was a bit tired :) [19:02:10] jdlrobson: how are you today jdlrobson [19:03:12] jdlrobson: could you take a look at https://gerrit.wikimedia.org/r/#/c/267519/ ? :) [19:05:27] FlorianSW: of course [19:05:29] jdlrobson: https://gerrit.wikimedia.org/r/#/c/269751/ [19:05:38] d3r1ck: very good thank you. Let me know if I can help you get stuck into any coding :) [19:06:02] phuedx: can you create a bug specifically for this problem [19:07:04] James_F should really be clear what's going on here and dr0ptp4kt and him really need to work out how to maintain this stuff better. Mobile web editing is not the reading teams responsibility. [19:07:06] ok jdlrobson [19:07:19] FlorianSW: ahh this patch [19:07:43] :P [19:08:09] FlorianSW: i agree the -2 is a bit harsh. I'd suggest writing a new patch which introduces a hook that BetaFeatures consumes [19:08:43] jdlrobson: ehh, one more hook just because of MobileFrontend? :/ I don't think this is a good idea :) [19:08:58] BetaFeatures already "publishes" the settings it provides :) [19:09:05] FlorianSW: did you see https://gerrit.wikimedia.org/r/236194 [19:09:37] a long long time ago I remember I'll took a look yes :] [19:10:14] FlorianSW: i personally wouldn't worry about blacklisting sections [19:10:36] just show them all. Given Special:Preferences needs a lot of work and is not linked to in interface I think it's fine to show even the irrelevant things [19:11:03] jdlrobson: before you go requesting responsibility from others, i believe we've ignored our browser tests for some 28 days [19:11:54] jdlrobson: if you mean, I don't have a strong preference about that, but think about that beta features are more poorly rendered on mobile as other sections (and the only reason doing it is for general support of all settings in mobile and to use beta features in Popups for mobile linkpreview :)) [19:12:17] phuedx: irrelevant. I'm just asking for a task to increase visibility of this issue. It's a tad more serious to be marked with "failing brower tests". [19:12:33] jdlrobson: relevant [19:12:39] we merged it, we ignored our browser tests [19:12:49] if you're asking for visibility, fine [19:12:58] phuedx: yes that is all i'm asking for. [19:13:06] phuedx: i want to make sure James_F knows this has happened [19:13:07] if you're asking other teams to take responsibility for something we broke? "Mobile web editing is not the reading teams responsibility." [19:13:17] as I suspect he hasn't got a clue [19:13:23] neither did we for 28 days [19:13:34] phuedx: I'm not blaming anyone. I don't know who broke what. [19:13:39] i suspect that i'm misunderstanding you [19:14:45] Put simply I'm making sure that James_F knows the mobile editor has been broken for X days for certain users. I'm concerned he will not be following a generic "MobileFrontend browser tests are failing" task. [19:16:11] fwiw I think it is my fault this time given I merged https://gerrit.wikimedia.org/r/#/c/268568/ [19:19:41] https://phabricator.wikimedia.org/T126497 [19:20:25] as the maintainers of the mobilefrontend extension, we bear some responsibility [19:20:52] we cannot and must not wash our hands of a part of a codebase we actively work on [19:21:28] I'm sorry you took my comment that way phuedx. [19:24:32] mdholloway: o/ hey! did my comment on the zero patch make sense? it just seemed like the way we're comparing the new headers is different than what yuri suggested [19:24:53] phuedx: so it looks like it's on the current train? [19:24:57] niedzielski, link? [19:25:03] but not on enwiki yet? [19:25:04] jdlrobson: it seems the bug i was working on yesterday has a long way to go :) [19:25:29] yurik: line 98 https://gerrit.wikimedia.org/r/#/c/269548/2/app/src/main/java/org/wikipedia/zero/WikipediaZeroHandler.java [19:25:52] jdlrobson: included in -wmf.13 [19:25:55] niedzielski: yep! i'll make the change but it still seems to me we can compare the strings as one concatenated string or separately and the logic will be more or less the same, we'll just save a couple of function calls. but i'm fine either way [19:26:17] niedzielski: was just about to make the change, actually [19:26:41] niedzielski: as for the toEquals and hashCode overrides in the updated ZeroConfig, any reason not to take those out completely? [19:27:16] niedzielski: er, s/toEquals/equals [19:28:48] mdholloway: 👍 i don't care about performance unless it's problematic, only readability. so if the logic is as intended, then that's cool with me. for hashCode and friends, isn't the equals used in PageActivity.onWikipediaZeroStateChangeEvent() ? [19:29:03] jdlrobson: reading your comment back, i think i misread it. i'm sorry about that [19:29:39] (no "but" either) [19:29:46] niedzielski, mdholloway - if you want to store both values (carrier & meta), and compare them each, that's fine too - totally up to you really [19:30:21] I see Krenair is on evening SWAT duty today. [19:31:05] I'm on the list every day [19:31:15] Krenair: would you be able to take care of https://phabricator.wikimedia.org/T124676#2015961 ? [19:31:22] yurik /cc mdholloway: thanks! i think i missed a parentheses in my head :) [19:31:48] I can be around if necessary (although i need to leave around 5pm sharpish) [19:31:49] jdlrobson, saw that, yes, should be able to deploy that patch during swat [19:32:35] sweet thanks Krenair. [19:32:54] niedzielski: yurik: as i understood it, the important thing is that we check for both, and get a new config when there's a change in either (rather than just relying on X-Carrier) [19:33:03] luckily phuedx caught it before it rolled out to all wikis so i guess damage is a bit low, but will explain any dips you see in edits on other wikis [19:33:11] mdholloway, correct [19:33:16] (although i guess you won't see those dips due to the sampling hah) [19:33:49] bmansurov: the other patches need to be merged first before MobileFrontend (Cards and Gather) [19:34:02] ill take a second pass at MobileFrontend when those are merged (as Jenkins will stop complaining then) [19:34:39] jdlrobson: I didn't see a patch for Cards [19:34:47] can you link to it in the commit message? [19:35:06] oh yeh sure [19:35:16] actually [19:35:21] Cards shouldn't depend on MobileFrontend [19:35:26] niedzielski: you're right, I see ZeroConfig.equals there in PageActivity.onWikipediaZeroStateChangeEvent() [19:35:36] so I'd say that's actually a mistake/bug in Cards that should be dealt with separately [19:35:42] jdlrobson: how come Gather does? [19:35:50] jdlrobson: oh i see [19:36:01] because Gather explicitly marks itself as a dependency of MobileFrontend and runs in the browser tests [19:36:07] niedzielski: I think I'm going to change those pausedStateOfZero and pausedMessageOfZero variable names [19:38:49] mdholloway: 👍 [19:39:01] mr jenkins is slow today.. [19:51:47] thanks, jhobs. :-) [21:08:53] dbrant mdholloway bearND: michael's patch looks good to me. any objections to merging? it seems like there's some trouble in ci land so it might not merge for a while. [21:13:37] releng said to make a bug for it. they're having a lot of slowness today because of some php upgrade, i think. anyway, here's the bug T126532 [21:18:08] niedzielski: no objections [21:23:46] jdlrobson: how does mobile web alter which cookies to set? [21:26:21] dbrant: cool. starting the ol release process. i'm planning to keep it abbreviated since we had so little change from the last release [21:26:36] excellent [21:29:16] sounds good [21:40:50] bearND dbrant mdholloway: i've been accruing some personal notes on the app release process i'd like to be better about updating on the wiki. does it make more sense to keep them on https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Release_process add a release section to https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_hac [21:40:50] king? i'm leaning toward the latter [21:42:42] niedzielski: i think the release process belongs to a different page since a volunteer contributor doesn't need to do this. We can add a link to it, though. [21:43:22] i mean separate page from the app hacking page [21:43:27] bearND: i mostly agree with that. currently, volunteers probably don't care but the Commons app was forked by volunteers after it was deprecated and now they care about the release process [21:44:45] niedzielski: agreed for putting it in the Release_process page. This stuff isn't really relevant to contributors [21:44:52] +1. [21:45:32] 👍 i'll keep it at Release_process then [21:45:45] niedzielski: i think a link from the hacking page to the release page is fine. My concern is that the hacking page is already so long and might overwhelm new people, if they think they have to follow all the step there [21:47:06] yeah, i was thinking it's getting pretty long, too. almost long enough to consider splitting up anyway. [21:47:59] mdholloway: if we're splitting things off, i think the java-mwapi is probably a good candidate [21:55:02] Hi mobile people. It looks like your hack for https://phabricator.wikimedia.org/T49647 doesn't work with SessionManager, because CentralAuthSessionProvider checks $wgCentralAuthCookieDomain in Setup.php (instead of much later when the cookie is being set). [21:56:13] hey tgr sorry missed your message [21:56:23] could you elaborate? [21:56:41] nevermind, found it [21:57:05] mobile web users apparently can't login due to cookie domain issues [21:57:11] a.nomie is working on it [21:59:58] jdlrobson: it seems our guy bmansurov fixed the bug i filled yesterday [22:00:02] thanks bmansurov_break [22:00:36] jdlrobson: reviewed it and it was Ok [22:02:35] bmansurov_break: thanks again for your help on the tests and the initial recommendation for them. Found a couple minor bugs from them, so successful endeavor! [22:02:48] hmm, isn't that entire 'entermobilemode' config hook a bit too late for what it's doing ? [22:03:58] ah, it doesn't know if it's executing on mobile before that time of course. [22:04:52] thedj: It is with SessionManager. Before SessionManager, the config variable was re-checked every time a cookie got set, so it was probably in time. [22:04:54] thedj: where are you seeing that hook? [22:05:20] and what's using it? [22:05:40] jdlrobson: https://gerrit.wikimedia.org/r/#/c/61941/1/wmf-config/mobile.php,cm [22:05:46] jdlrobson: https://github.com/wikimedia/operations-mediawiki-config/blob/0ccdd29/wmf-config/mobile.php#L73-L84 [22:06:12] ah i see [22:06:18] or better, https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/mobile.php#L68-L79 [22:06:20] okay i guess that's legit. (there's also MobileSiteOutputPageBeforeExec) [22:10:30] wouldn't it be better, if we had some sort of config var with domain mappings, and then we'd have a mobile transform function that could operate on vars like wgCentralAuthCookieDomain, when used to output a value (and it would modify depending on the type of context) ? [22:11:30] dbrant: do we want to skip tsg testing on this one since the delta is small? [22:11:31] or we should just set a different wgCentralAuthCookieDomain if we set a different wgServer i guess :) [22:13:08] thedj: I don't think MobileFrontend ever sets a different wgServer, instead it relies on hacky calls to MobileContext::getMobileUrl( $url ) all over the place... [22:13:16] niedzielski: yeah, i suppose. They don't have test cases for W0 anyway... [22:14:48] niedzielski: dbrant: i was going to say more testing never hurts and our testing budget is as i understand it far from exhausted, but yeah, i guess we don't really have testing in place for the major change anyway. [22:17:34] thedj: in theory yes but in practice these kind of changes are hard to get momentum behind [22:17:45] tgr, bd808, thedj, jdlrobson: If getting $wgCentralAuthCookieDomain hacked up early enough is too difficult, another option would be to adjust the 'WebResponseSetCookie' hook to pass $options by reference and then have MobileFrontend hack up $options['domain']... [22:19:55] jdlrobson: well if users' can't login anymore, i'm guessing that should be motivation enough :) [22:25:10] thedj: wait.. are you saying users cant login? [22:25:22] not on commons and meta no. [22:26:08] i just logged in on meta now.. [22:27:01] oh wait just tried an incognito window and got "Central user log in" error. Guess that's what you mean? Are you tracking this bug anywhere? [22:27:26] Central user log in [22:27:27] No active login attempt is in progress for your session. [22:27:47] jdlrobson: i don't think there is a ticket yet. [22:27:49] bearND dbrant mdholloway: no regressions found. i'm moving forward with the release unless there are objections [22:28:03] +2 [22:28:07] sounds good to me [22:28:10] anomie: or allow the provider config to be reset and make the enter-mobile hook do that? [22:28:11] thedj: this has come up numerous times before. I've seen it before and tackled it numerous times with csteipp :/ [22:28:15] which is a bit meh [22:29:06] niedzielski: sounds good! [22:29:50] wait// [22:29:52] jdlrobson: It's https://phabricator.wikimedia.org/T49647 all over again, basically. [22:30:02] why can't you just unconditionally set that in mobile.php - those config changes should only apply on the mobile domain [22:30:08] why do you need the hook at all? [22:30:27] tgr: a reset sounds like something you don't want to deploy as a hotfix really [22:31:25] hmm.. i guess they run everywhere but only on sites with a mobile domain. [22:41:33] jdlrobson: I reopened https://phabricator.wikimedia.org/T49647 to track this issue. [22:48:15] bearND dbrant mdholloway: looks like that sweet bump version commit is hanging around on ci. please hold off on merging things until that goes through [22:49:00] it's taking its time to savor it [22:49:39] niedzielski: Roger that [22:49:55] :) [23:45:03] niedzielski: hey do you remember talking about exploring native chrome-like tabs? [23:46:02] kaity_: yep, i don't think we got into much detail but it seems like a nice feature if we're going to keep the tabbed browsing concept [23:47:22] niedzielski: cool. I think we keep tabs for sure, is there a phab task associated with it? [23:48:26] kaity_: i believe so. let me take a peek [23:48:42] thanks! [23:49:25] kaity_: i think this is it: https://phabricator.wikimedia.org/T116494 [23:52:39] niedzielski: thank you! [23:52:50] np :)