[00:34:26] does anyone know of any change affecting mobileview output that went live today? i'm seeing an extra opening div "
" without a closing div. example: https://test.wikipedia.org/w/api.php?action=mobileview&format=json&page=Bird4§ions=all&prop=text%7Csections [00:42:01] jdlrobson: ^ hey would you know of anything which went live recently which could be causing this? [00:44:27] Mystery opening div without matching closing div https://usercontent.irccloud-cdn.com/file/cNzfeo82/Screen%20Shot%202017-05-11%20at%205.42.43%20PM.png [00:45:25] First noticed on "enwiki > Tony Blinken". seems to go away if i remove the "External links" section [00:46:39] mdholloway|afk: bearND|afk: ^ [00:49:36] mhurd: i think this is the change: https://gerrit.wikimedia.org/r/#/c/350634/ [00:49:46] phab: T37247 [00:49:47] T37247: content-holding
should only contain the page text - https://phabricator.wikimedia.org/T37247 [00:50:07] looks like mobileview sectionizing isn't doing well with it. :[ [00:50:57] mdholloway: haha no it is not :/ [00:51:38] mdholloway: thx for the info! would you know where we should file this? [00:52:31] Probably MobileFrontend [00:52:50] looks like the change is going into Parsoid too but not sure if it's been deployed yet, checking now [00:53:06] mdholloway: gotcha. i'll start writing it up... [01:01:28] mdholloway: ticket here - https://phabricator.wikimedia.org/T165115 [01:02:09] mdholloway: feel free to edit it as needed :) [01:03:32] mhurd: thanks! [01:10:54] mhurd: is this breaking the iOS app page content? it doesn't seem to have any negative effect on the android app even when loading from mobileview [01:13:49] mdholloway: i've only noticed one style issue (which is what tipped me off to the issue). however, there may be other issues we just haven't noticed yet. even on android, if the layout looks relatively ok that new opening DIV is now taking some other DIV's closing div as its own, and your DOM may only look normal on some pages just by luck [01:14:44] mdholloway: almost any section's html could cause it to break in unpredictable ways [01:14:49] is there a page that this is happening consistently on? not seeing it on en tony blinken, actually: [01:14:49] https://en.wikipedia.org/w/api.php?action=mobileview&format=json&formatversion=2&prop=text%7Csections%7Clanguagecount%7Cthumb%7Cimage%7Cid%7Cnamespace%7Crevision%7Cdescription%7Clastmodified%7Cnormalizedtitle%7Cdisplaytitle%7Cprotection%7Ceditable%7Cpageprops&pageprops=wikibase_item&onlyrequestedsections=1§ions=0§ionprop=toclevel%7Cline%7Canchor&nohe [01:14:50] adings=true&page=Tony_Blinken&thumbwidth=640 [01:15:00] sorry, link too long [01:15:17] mdholloway: it's like the DOM equivalent of a free radical. [01:15:24] mhurd: makes sense. [01:15:43] mdholloway: it is happening on tony blinked, it just doesn't look broken with the android index.html structure [01:16:38] mdholloway: i may have way for you to see same effect on android i'm seeing... lemme test it real quick.... [01:19:57] mhurd: ok, i see it [01:20:02] on barack obama [01:20:12] mdholloway: ah cool [01:20:15] breaking lead para shifting at least [01:20:34] mdholloway: ya same on tony blinken now that i look at it [01:21:46] mdholloway: i think they just need to exclude it from mobile view sections, given that section are about the html inside the sections, and shouldn't include parts of overall container divs, which this new one seems to be [01:22:02] mhurd: yeah, i think that's right. [01:26:55] mdholloway: i added a comment to that effect to the ticket [01:27:14] mdholloway: wish i had noticed this earlier today :/ [01:28:29] yeah. i imagine it's only been live on enwiki and most others for a few hours, since today's mw train [01:30:59] mdholloway: true [01:31:04] mdholloway: as we've been consolidating apps transforms @niedzielski and i have been adding tests but we don't have any wired up quite yet which could have caught this... soon!!! [01:32:07] mdholloway: though technically upstream tests could have done so as well [01:35:35] mdholloway: i'm going to create an iOS ticket tracking the broken paragraph transform and link it to the ticket i just created. you may want to do same for android? [01:35:49] mhurd: sure, good idea [01:38:02] mdholloway: well, beyond that i think we've done what we can for tonight [01:38:37] mdholloway: thx again for all the help! [01:38:48] mhurd: no problem, thanks for the heads-up! [01:39:01] mdholloway: yw! have a good night! [01:39:07] mhurd: you too! [10:33:24] Anyone around who knows something about the Wikipedia app map tiles and the tokens that are used to get the tiles [10:34:19] tobias47n9e: I know a little bit, but the android developers would know more [10:35:40] not sure what you mean by token - are you talking about the URL path components? [10:36:13] joewalsh: We were wondering if we need a new token for the commons android app [10:36:36] Like to access to tiles, and not look like stealing bandwidth [10:37:59] tobias47n9e: yeah, unfortunately I don't know anything about that. but niedzielski, mdholloway, or dbrant_ should be able to help [10:38:29] joewalsh: Thanks [12:11:42] hello, https://commons.m.wikimedia.org/w/index.php?title=Main_Page&mobileaction=toggle_view_mobile content missing in mobile version. any idea how to fix? [13:38:56] hey dbrant, tobias47n9e was asking earlier about tokens for getting wikimedia app tiles. can you help him out? unfortunately i don't know anything about this [13:41:33] tobias47n9e: tiles, as in, for maps? [13:47:23] dbrant: Yes [13:47:25] yes, map tiles, sorry i omitted a word [13:48:29] tobias47n9e: I don't believe you need a token. They're simply retrieved via a url in the form https://maps.wikimedia.org/osm-intl/{z}/{x}/{y}.png [13:48:58] We were wondering if we need/can/should use this: https://github.com/commons-app/apps-android-commons/pull/553/files#diff-01dafb3fd0217441330103cfc8300094R170 [13:50:02] tobias47n9e: ah, that token is only needed to satisfy the Mapbox SDK. For some reason it doesn't initialize without a token. But it doesn't actually use this token for fetching the tiles. [13:52:17] dbrant: Thanks. And there is no issue if we use the same token? It is not used for traffic analysis or something? [13:54:41] tobias47n9e: there shouldn't be any issue. We copied that token from one of Mapbox's samples. And regarding traffic analysis, we explicitly turn off the Mapbox telemetry service, so that it doesn't send any data. [13:55:04] dbrant: Most helpful. Thanks! [13:55:09] anytime [15:03:06] reets_afk android standup? :D [15:03:36] hey, i'm seeing about 15-20k logs per minute that say roughly 'MFCustomLogos config option is deprecated. Please use MinervaCustomLogos instead.' Could someone put together a config update? [15:27:45] ^ jdlrobson, heads up. ebernhardson jdlrobson doing the reading web tech lead role [15:29:22] ^^ phuedx, heads up to you as well [15:34:12] hey hey, just fyi the extracts problem is being investigated [15:54:55] mobrovac: cool, thx [17:28:30] dbrant: niedzielski: Any other breakage you've seen in the app in the past ~24 hrs beyond the lead para issue and summaries not appearing in link previews and TFA cards? [17:29:01] nothing besides that, i think. [17:29:16] same [17:46:04] dbrant: niedzielski-afk: cool, thx [18:19:12] dr0ptp4kt: not sure about hovercards. i'm on ca.m.wikipedia.org and have beta features enabled and i'm hovering over article links and seeing nothing. (so maybe that's a yes, went boom?) [19:34:53] mdholloway: don't be logged in when using it. hovercards (now page previews) i think only uses restbase when anon. < bmansurov can you confirm? [19:36:20] dr0ptp4kt, let me check, it's config variable configurable [19:38:28] dr0ptp4kt, mdholloway Popups uses restbase on it, ru, el, ca, he, and huwikis. [19:41:30] mdholloway, popups works on the desktop site only [19:42:28] bmansurov: dr0ptp4kt: i'm totally ignorant of the popups architecture but if it's using content ultimately provided by TextExtracts it would presumably be broken either way, RESTBase or otherwise [19:42:46] RESTBase summaries just pass TextExtracts extracts through [19:43:01] with some other content aggregated from elsewhere [19:46:51] mdholloway, yes, I'm confirming that Popups is working on https://ca.wikipedia.org when enabled via preferences. [19:47:18] not sure about the bigger issue with TextExtracts, but RESTbase maybe returning cached extracts [19:55:20] the MW side of things has been fixed [19:55:31] however, we now need to regenerate RB summaries [20:35:30] mdholloway bmansurov sorry for delayed response. meetings. so i gather we're not learning of parser cache corruption *at the moment* for the select set of pages viewed with Hovercards (possibly a symptom of pages often being frequently updated through templates or bots). but mobrovac is saying that rb responses have to be regen'd (do we know that the parser [20:35:30] cache is all clear?) [20:42:07] dr0ptp4kt: AIUI, the issue is resolved on the MediaWiki/TextExtracts side (i.e., the parser cache issue is all clear). Some cursory testing I did just now supports this. [20:42:48] ok, so no need for anyone to be worried that there's a long tail of corruption ;P [20:43:19] dr0ptp4kt: RB responses for the /page/summary endpoint will need to be regenerated since they got bad responses from ApiQueryExtracts (TextExtracts). [20:46:20] i wouldn't necessarily take me as the final word esp. with respect to the MW side, but from everything I've seen the problems were isolated to these two parser cache consumers (ApiMobileView and TextExtracts) and their downstream consumers (RESTBase for the latter and the apps for both). [20:46:48] and whatever Reading Web consumers may exist. [20:57:12] dr0ptp4kt: the parser cache has been cleared [20:57:22] we need to fix the RB titles that got updated [20:57:24] in the last 24h [20:57:59] mobrovac: thanks, i probably should have read the fine tickets and would have noticed that they were cleared! thanks for telling me, though :) LOL [20:59:35] hehe no pb [20:59:38] busy day