[14:40:00] mdholloway: if you're working on the edit pencils, mind basing it on top of https://gerrit.wikimedia.org/r/337915 ? [14:49:31] dbrant: good idea, will do [14:50:04] looks like that needs reviewers, btw, mind if i add stephen and myself? [14:50:14] git reviewer bot taking some time off again [14:50:20] oh shoot, of course [15:46:31] dbrant: niedzielski: looks like a regression slipped through on master: the top two items on the trending feed card do nothing when clicked [15:47:40] mdholloway: hm, i'm not seeing that on my end [15:47:45] can't repro... [15:47:52] what language are you on? [15:49:19] it's happening for me persistently... but only on english. [15:50:16] hmmm... and only the first item on some cards... something really screwy is going on here. [15:50:23] some "because you read" cards are affected as well. [15:51:59] mdholloway: anything in the log? [15:52:08] mdholloway: nvm, it's happening for me :| [15:52:17] nothing in the log [15:52:41] seems like an onclick listener isn't attached for some reason. [15:56:31] scratch that [15:57:22] callback in PageTitleListCardItemView is unexpectedly null in some cases [15:58:10] mdholloway: sounds like your digging into it. let me know if i can help! otherwise ima keep working on these patches [15:58:18] niedzielskii: sounds good [17:04:28] https://etherpad.wikimedia.org/p/app-strategy-discussion [17:24:29] it's a morning for the black album [17:26:23] 99 edits and a revert ain't one [17:31:10] encore encore [17:48:47] is revert an edit technically? [18:02:26] niedzielskii: dbrant: i've got to run in a minute, but in case you were in suspense, the list item regression was caused by (drum roll) -- the support library upgrade! [18:02:29] i said a revert ain't one, see? [18:02:43] not sure why yet [18:02:57] * mdholloway away! [18:03:02] thanks michael! [18:08:17] + [18:39:27] hello all, I just recently noted something in the alpha version of the app. if my analysis is correct the Description editing option is not shown for pages not in main namespace. is that correct? [18:49:41] kaartic: correct. It should only be available when the page is linked from a Wikidata item. [18:54:12] in that case, I noticed that the following article which is in the Template namespace and for which no item exists in wikidata, the edit title description option is shown. https://en.wikipedia.org/wiki/Template%3AMedia_request_templates?wprov=sfla1. . [18:54:40] is there any reason begin that? [18:55:03] sry, begin -> behind [18:59:33] I guess I got another one, https://en.wikipedia.org/wiki/Template%3ATable?wprov=sfla1 [18:59:50] I couldn't find a item for both in wikidata. [19:02:19] i could see it many articles not in main namespace and for which the "Edit title description" option is shown. Is this a problem? [19:02:33] *it in many [19:04:06] Just in case, here's another https://en.wikipedia.org/wiki/Template%3AClarify_span?wprov=sfla1 [19:06:49] kaartic: all of those do, in fact, have items in Wikidata. [19:07:23] in the app, we're simply limiting it based on whether the page exists in Wikidata, not by namespace. [19:09:09] dbrant: sry, I relied on the search a bit more than I should have. Searching for "Template:", I didn't get the results. [19:10:13] BTW, what is the criterion for showing "Add title description" for an article. [19:10:51] correction: . -> ? [19:32:26] mhurd: can you send me a link to the contribs page of the account? [19:36:39] one more thing I noticed is that for some articles even though a wikidata item exists the "Edit title description" option is not shown. [19:36:47] for example, https://en.wikipedia.org/wiki/Template%3AISO_3166_code_India?wprov=sfla1 [19:37:07] https://en.wikipedia.org/wiki/Template%3AWikiProject_Astronomy%2Fimportance?wprov=sfla1 [19:53:41] kaartic: that's because those pages are protected and cannot be edited with the current account's privileges. [19:58:42] dbrant: do you mean it's protected by wikidata, sir? [19:59:25] no, it's protected on Wikipedia, but we're using that protection level to disallow editing of the descriptions. [20:04:12] if I'm right, I shouldn't be allowed to edit the article if I don't have that privilege, sir. I'm able to edit the article but unable to edit the title description [20:21:35] dbrant: I just now saw that I am unable to edit the page even though the edit icon is available, sir. wouldn't it be better to avoid showing the edit icon for articles that a user could not edit [21:57:21] HaeB: there? [21:57:26] hi [21:57:32] schema is halfway there https://phabricator.wikimedia.org/T155639#3034663 [21:57:50] but bmansurov points out what we were trying to explain to one another yesterday [21:57:54] do you want to revisit? [22:00:12] jdlrobson: thanks, shall i follow up on the task? [22:01:18] yup, you can also talk it through here before hand if that helps [22:01:33] would be good to reach a decision and just post on task for prosperity to avoid confusion [22:31:35] HaeB: so to be clear... anything hidden before first paint can be ignored? [22:32:43] jdlrobson: for the visibleLength metric? [22:33:50] basically if first paint occurs at 26s and the user leaves at 27s you will have no way to know whether that's because the page took 27s to load or because the user opened the page in another tab [22:33:54] yeah we should only count the time from after the tab becomes visible again, even if it's painted before that [22:34:04] in such a case we would measure 1s for session length and 0 for hidden [22:35:27] but we would also record firstPaint as 26s [22:36:14] HaeB: that last message seems to be contradictory.. If page is fully opened in a new tab, first paint will be the same time the user tabs to it [22:36:24] which will give a very different result to a browser where we use domInteractive [22:37:04] (well it depends on the browser loading strategy) [22:37:19] ok, i thought there are cases where it's painted before the user opens the tab [22:37:20] right [22:37:43] so say you have DomInteractive of 2s and FirstPaint of 20s and unload at 21s [22:38:20] so i think the definition of visibleLength is pretty unambiguous... are you more concerned that we don't have enough information to investigate the reason for high firstPaint times? [22:40:07] that may be a limitation we need to live with. IIRC the performance team had pretty much the same issue with NavigationTiming a while ago, and decided (i seem to recall) to exclude hidden loads from performance analysis [22:41:27] HaeB: the reason im confused is to why we are even caring about time visible if the page is being loaded in a new tab. [22:42:24] https://phabricator.wikimedia.org/T155639#3013160 [22:42:32] Do we have the case covered that the page is loaded in hidden state (happens e.g. when a link is opened in a new tab in Chrome) - in other words, when the timer for visibleLength needs to be paused right from the beginning? [22:42:48] there's no need to pause the timer in such a case because we are measuring from first paint [22:45:12] well, we still need to record when the tab comes into focus, because that should be taken as the starting point for visibleLength *if* it comes after first paint [22:46:25] the concern in https://phabricator.wikimedia.org/T155639#3013160 was that maybe we could erroneously assume the tab is visible because there had been no hide event yet [22:55:20] HaeB: I fear i'm just confusing us even more and I'm not quite sure right now how to explain better, so let's try something different: [22:55:21] https://etherpad.wikimedia.org/p/sessionlength [22:58:31] I think some examples would help illustrate this problem best