[00:10:29] niedzielski: hey you there? [00:10:43] jdlrobson: o/ [00:11:18] so... im a little baffled about something and im hoping you can enlighten me... when a user does an edit on android, and you refresh the page after a save... how do you make sure you show them the new content? [00:11:34] jdlrobson: well... [00:11:51] jdlrobson: we don't have a good solution for that yet AFAIK when using the content service (MW API works fine) [00:12:16] ahh.. so you use MW API? [00:12:23] but how do you deal with the change in presentation? [00:13:11] niedzielski: talking to gwicke and Pchelolo i think https://phabricator.wikimedia.org/T146836 is the solution. [00:13:16] jdlrobson: right now, when using the content service we wait a couple seconds and hope for the best :] it's not bulletproof. michael's exploring changing the content locally [00:13:35] niedzielski: that strategy doesnt work on smaller projects e.g. wikivoyage [00:13:56] so if https://phabricator.wikimedia.org/T146836 is fixed - what you can do is take the revision number from the edit response and request the new revision [00:14:52] jdlrobson: we've talked about checking for the revision but how long do you wait? do you ultimately still show a "cahnges processing" kind of message if it takes too long? [00:16:11] you wouldnt check.. you'd request... so instead of requesting https://en.wikipedia.org/api/rest_v1/page/mobile-sections/San_Francisco you'd request https://en.wikipedia.org/api/rest_v1/page/mobile-sections/San_Francisco/753467486 [00:16:51] jdlrobson: i think thought the issue was that the cache isn't updated for 2+ seconds [00:17:07] but if you're hitting the above url there would be no cache [00:17:12] so it would generate [00:17:17] that's apparently how VisualEditor work around this issue [00:17:21] jdlrobson: oh wow [00:17:53] jdlrobson: well, we're not doing that :] but it sounds like the way to go [00:18:07] niedzielski: okay.. im gonna write a patch for this, cos i want this fixed too :) [00:18:20] is there a bug for the editing problem? [00:19:12] jdlrobson: sweet, thanks for the heads up! this is the current open issue (it's come up a few times): T152207 [00:19:13] T152207: Description changes are not reflected without refreshing the page after a description is added or edited - https://phabricator.wikimedia.org/T152207 [00:19:46] jdlrobson: i think this particular tasks also refers to the issue where you make an edit on one device and then quickly check on another [00:20:44] jdlrobson: but that would be a corner case if we used your approach [00:21:13] descriptions maybe trickier [00:21:22] so the problem with descriptions is they are not revisioned [00:22:53] jdlrobson: oh geez [00:23:19] neither are page images [00:23:38] so a request to https://en.wikipedia.org/api/rest_v1/page/mobile-sections/San_Francisco/753467486 would always return the latest description and page image [00:23:42] jdlrobson: do you know, if transcluded content changes, does that give a page a new revision? [00:23:45] but that's probably fine in this context [00:24:00] niedzielski: nope.. another edge case.. [00:24:18] the main thing this would help is if you edit a page and it refreshes you see the new version [00:24:21] jdlrobson: so we couldn't even fake a description revision with a transclude [00:25:14] jdlrobson: well, that would still be a huge win over the current implementation [00:33:12] jdlrobson: would you mind adding me to that patch whenever you have it? i'll make a ticket for android and ios (if it's there) to update article editing [00:33:17] will do [00:40:10] 👍 [00:55:16] niedzielski: patch incoming [00:55:17] it is odne [00:56:10] cool, thanks! [00:56:29] niedzielski: was really simple - https://gerrit.wikimedia.org/r/326868 [00:57:03] niedzielski: this also means we can update our tests so they never fail [00:57:09] (ie. when content changes) [00:57:42] my flakies! [10:04:06] joakino: good morning! [10:04:17] I noticed a bunch of your Popups changes have failed the CI [10:04:35] there is a slight chance I have broke CI : [10:04:36] ( [10:05:03] though apparently the tests failures are unrelated to my change [10:05:42] hi hashar! [10:06:08] there's probably things to fix on them, I'll ping you if there's something out of place haha [10:06:16] thanks for checking [11:29:52] niedzielski: hello sir, are you around ? [15:52:15] kaartic: o/ [16:03:03] yayyyy, android 25 sources [16:25:21] dbrant mdholloway: is it just my system or does grrrit no longer show images in code review? [16:28:29] niedzielski: example patch? [16:28:44] dbrant: https://gerrit.wikimedia.org/r/#/c/325819/5/app/screenshots-ref/org.wikipedia.descriptions.DescriptionEditViewTest.testFocus-480dp-en-ltr-font1.0x-dark-saving.png,unified [16:29:34] yep, not seeing images [16:29:54] ok cool, thanks [16:33:32] T153085 [16:33:32] T153085: Gerrit doesn't display committed images - https://phabricator.wikimedia.org/T153085 [17:32:25] niedzielski: dbrant: ah, yes (sorry, saw this notifcation then forgot) -- image viewing is another victim of the gerrit upgrade, i think [17:34:00] mdholloway: meeting time [17:34:14] thx omw [18:53:50] niedzielski: It seems that currently the app is starting to take up more memory than it previously did. [18:54:28] kaartic: hm, significantly more? [18:54:31] Do you remember the bug reported here: https://phabricator.wikimedia.org/T151300 [18:55:25] i do [18:56:37] as you said I tried logcatting, when the issue occured. The only thing i could see relevant to it was the line that reads something like "The app is doing more work in the main thread, skipping x frames" the value of 'x' changed [18:57:12] also, after the recent beta release, I see the issue in the beta app too. [18:58:07] hm, i think you would see an out of memory exception in the logcat if it was a memory issue :[ [19:00:07] i think it's not going out of memory, just consuming more memory. Is that logcat statement above, related to this issue ? [19:04:10] i don't think so. skipping frames means the ui might be laggy but it should still render correctly. for example, you might see an animation stutter but the final frame should appear accurately [19:06:36] but as you could see in those screen shots, I do not get the final frame accurately and the only thing I could fin in logcat until now is that line. I'll see if I could find something else that's realted. [19:09:26] niedzielski: one more thing wanted to ask was, Is the "Continue reading" card shown for "User talk" pages with reason ? [19:11:59] kaartic: i think you should only see it if you visited a user talk page in app. we only filter out the main page [19:13:05] kaartic: i think our page namespace column in the database has some legacy strings in it if we wanted to do more sophisticated filtering reliably [19:13:41] kaartic: the query is in LastPageReadTask. the columns available are in PageHistoryContract [19:15:38] niedzielski: I did see it after i viewed a talk page in the app. but is it good to show continue reading cards for talk pages ? [19:18:03] kaartic: i'm not quite sure. however, i *think* the only way you can get to a talk page is if you know about the talk namespace and search for "Talk:Page title" (or click a link) so it's probably less common an issue but i think the work to filter out talk pages would be a bit more involved (but the refactor would be valuable long term). [19:18:29] kaartic: if you have a strong opinion about it, i do recommend making a phab ticket to track the discussion! [19:19:38] niedzielski: ok, i'll open one tomorrow. see you later. have a great day. [19:19:56] thanks kaartic! you too! [19:20:53] niedzielski: thanks [19:36:38] niedzielski: mdholloway: i have a theory [19:36:47] dbrant mdholloway: wikisite is nonnull but scheme and authority are null [19:36:47] batcave for 1 min? [19:36:52] sure [19:37:02] sure [19:55:07] dbrant mdholloway: the database was bumped to 9 in 50e93b21d04cf74587bfde50f8cb0d714bf52d47, released in beta/2.1.142-beta-2016-03-07. so anything from beta/2.1.141-beta-2016-02-10 or earlier should stimulate the issue [19:55:19] thanks! [19:59:24] dbrant mdholloway: upgrading from 8 to 15 with a few open tabs does not repro the issue. all tabs are lost though [19:59:33] i tried french wikipedia [20:00:15] dbrant mdholloway: i've got a meeting momentarily but i'll try a few different ways again afterwards [20:00:32] cool [20:14:04] niedzielski: mdholloway: repro'd, by faking out the serialized tab list. [20:14:29] dbrant: \o/ [20:31:18] dbrant: awesome [20:59:02] mdholloway: is it cool if we hold off on merging https://gerrit.wikimedia.org/r/#/c/326033/ until after the release? [20:59:36] dbrant mdholloway: i'm going through open patches on https://gerrit.wikimedia.org/r/#/projects/apps/android/wikipedia,dashboards/default . anything else we're waiting for on a release tomorrow? [21:00:15] niedzielski: yeah, no need to rush it, just hopefully before description editing hits beta [21:01:05] niedzielski: nothing else from my end! [21:01:22] niedzielski: nothing else that i'm aware of. [21:33:55] dbrant mdholloway: ok cool. dbrant, do you want me to do the release tomorrow or are you up for it? [21:34:23] niedzielski: i'll be happy to. [21:34:52] dbrant: awesome! [21:54:00] Hi! anyone have any thoughts on googleweblight proxy? [21:54:52] We're looking at disabling JS on that proxy because CentralNotice issues (that's the urgent problem) but it doesn't seem that JS can provide much benefit there, in any case... [21:55:30] https://gerrit.wikimedia.org/r/#/c/327043 [21:56:30] a proxy server that interprets the js… [22:06:51] yep [22:06:58] None of our JS is served on the client really [22:43:10] bmansurov, jdlrobson thoughts on the question ^ from AndyRussG? [22:43:37] heads up olliv when you're back online ^ [22:51:50] AndyRussG: isn't google web proxy a black box that could disable JS itself? [22:52:38] jdlrobson: hi! don't know if this is the same as google web proxy... It basically remakes the entire page. None of or JS is served to the end user... [22:52:42] i think it's fine to disable though, but i'd tread carefully with anything that is maintained outside the wikimedia ecosystem - it may be better to reach out to Google directly about the problem . [22:52:48] s/or/our7 [22:52:56] s/or/our/ [22:52:56] sorry googleweblightproxy [22:53:12] yeh im familiar with it.. but that seems like a bug that google should deal with not us [22:54:33] jdlrobson: mmm yeah we did e-mail them, no response so far. The urgent issue is that it's serving a FR banner to all users (since the servers are in the US) and it's re-munged the page so that any place you click takes to you a FR payments form, that doesn't work.... [22:57:14] We're quite sure we want to disable banners for users of that service--since it munges the page so badly, even community banners probably should go. One option is to add a Varnish rule for Special:BannerLoader, to block specifically that UA [22:57:31] For an unknown reason the in-banner JS that was just added is not working [22:57:42] AndyRussG: hi, given that we handle other browsers in a similar fashion, I see no issues doing so in this case too. [23:00:04] AndyRussG: it seems weird to me that we are debugging an issue with a Google product... [23:00:31] AndyRussG: I understand it may have implications on our fundraising... but it's a blackbox. Disabling the user agent may help, it may not. [23:02:04] it would be like us to debugging an issue with banners showing up in the google knowledge engine on the right of google search results... [23:02:47] jonkatz: 2 min [23:02:53] bueno [23:08:52] mhurd: https://en.wikipedia.org/wiki/December_13 https://de.wikipedia.org/wiki/13._Dezember [23:16:35] jdlrobson: yeah... I mean, basically we're poking around to figure out what the best solution here is [23:17:06] Also confirmed with bblack that a Varnish rule is doable [23:17:34] If it were totally clear that JS should be disabled for this client, that'd probably be the most elegant route [23:18:28] However, if it's not clear, then maybe we should go Varnish, and let the bigger question of JS or no be duly considered [23:26:38] dr0ptp4kt: jdlrobson bmansurov it sounds like we need more time to consider how to deal with this service? [23:28:31] AndyRussG: are you saying we need more time to think expansively about it, or with respect to the immediate term issue? [23:29:30] AndyRussG: depends on how many users are using the site via googleweblight [23:29:39] It looks pretty bad: https://googleweblight.com/?lite_url=http://en.wikipedia.org&re=1&ts=1481671733&sig=AF9NedmQEY_blXmAAAqc93NeSpnKw7SRZg [23:29:48] even worse when interacted [23:30:33] dr0ptp4kt: it's just that I hear some disagreement and for FR we need to take some sort of action right away. So, if there's disagreement on whether to disable JS here, we're totally fine going another route :) just want to figure out what's best both in the immediate and medium-term [23:30:57] the whole site, except for links, acts like it's wrapped in an invisible ad shield that brings up the banner [23:31:01] bmansurov: I found 2.6 million FR banner views in one day via the service. [23:31:33] Yeah and that goes to people all around the world, apparently [23:31:44] AndyRussG: users must be pretty upset [23:31:52] unless you're getting that much donations too [23:31:52] And the click on anywhere in the site takes you to a payments page that doesn't work [23:32:00] oops then [23:32:04] yep [23:32:36] jdlrobson may have good concerns about us not fixing their product, but I think this JS solution (if it works) is a good immediate fix [23:32:37] the task is now public btw [23:32:39] T152602 [23:32:40] T152602: Spurious Amazon clicks / Banners on googleweblight.com - https://phabricator.wikimedia.org/T152602 [23:33:28] to be clear i think the solution is fine in terms of deployable code, im just not convinced it will 1) fix the problem and 2) should be our problem. [23:33:56] As Pcoombe (the-wub here) noted, the temporary fix of injecting some js into the banners for some reason didn't work https://phabricator.wikimedia.org/T152602#2870971 [23:33:58] but choose your own adventure! (but you'll need to okay it with krinkle i suspect) [23:34:13] yes he has been ping'd :) [23:34:58] jdlrobson: those sound like reasons to possibly not go with the disabling-JS solution, since the reason we turned to it is that it seemed the nicest [23:35:37] we have similar issues in mobile with Opera Mini and UC browser in data savings mode [23:36:11] it's really hard to understand how these will behave - we swatted a fix which should have made search work on UC mini but it worked for every wiki except English Wikipedia... as they are clearly doing something different for that specific domain that we cannot possibly fathom [23:36:20] all in all it was a waste of our resources imo..... [23:37:04] aaarg :( sounds frustrating [23:37:59] K that sounds like an argument for trying the JS solution [23:38:43] AndyRussG: able to hop on a hangout with me? [23:39:16] AndyRussG: i'm inviting you to a hangout