[01:35:54] 10VisualEditor, 10MediaWiki-General-or-Unknown, 6WMF-Design-Research: MediaWiki's feedback tool interface is confusing - https://phabricator.wikimedia.org/T100011#1618998 (10Nirzar) @aripstra @Elitre I think what i had in mind was simplifying the feedback process by introducing feedback categories {M80}... [02:40:52] NumberedExternalLink behaviour is a little strange in MF [02:57:37] (03PS1) 10Alex Monk: Load visualeditor-saveerror-titleblacklist and fancycaptcha-reload-text for all targets [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237016 [03:54:33] 10WikiEditor, 7Documentation: WikiEditor documentation is inadequate for user development - https://phabricator.wikimedia.org/T52917#1619275 (10Liuxinyu970226) [03:59:24] 10VisualEditor, 10VisualEditor-MediaWiki-Templates, 3Discovery-Cirrus-Sprint: autocomplete of templates selects unexpected template - https://phabricator.wikimedia.org/T111598#1619280 (10LuisVilla) 5Invalid>3Open Attached is what I see; enwiki, Firefox, Linux. I believe I also see the same on Firefox Mac... [04:04:24] 10VisualEditor, 10VisualEditor-MediaWiki-Templates, 3Discovery-Cirrus-Sprint: autocomplete of templates selects unexpected template - https://phabricator.wikimedia.org/T111598#1619282 (10Deskana) >>! In T111598#1619280, @LuisVilla wrote: > Attached is what I see; enwiki, Firefox, Linux. Confirmed. I cannot... [04:06:44] 10VisualEditor, 10VisualEditor-MediaWiki-Templates, 3Discovery-Cirrus-Sprint: autocomplete of templates selects unexpected template - https://phabricator.wikimedia.org/T111598#1619288 (10Deskana) The queries that are issued by VisualEditor in both browsers are identical, and in both the CNBLUE result's index... [07:34:11] 10VisualEditor: Some kind of filtering or security software inserts an HTML comment when editing with VisualEditor - https://phabricator.wikimedia.org/T111906#1619638 (10Amire80) 3NEW [08:43:39] 10VisualEditor: VE breaks on faked section edit links - https://phabricator.wikimedia.org/T111919#1619860 (10Schnark) 3NEW [09:14:48] 10VisualEditor, 10Parsoid, 10RESTBase: VE adds tags due to RB sending the wrong data-parsoid to Parsoid(?) - https://phabricator.wikimedia.org/T111491#1619924 (10mobrovac) >>! In T111491#1617911, @GWicke wrote: > PR to require the tid to be present at https://github.com/wikimedia/restbase/pull/321. The... [09:25:35] 10VisualEditor, 10VisualEditor-MediaWiki: Copying MW extension nodes out of VE results in no rendering - https://phabricator.wikimedia.org/T111923#1619971 (10Esanders) 3NEW [09:27:54] 10VisualEditor, 10VisualEditor-MediaWiki: MW extension node renderings not shown in reference preview - https://phabricator.wikimedia.org/T111924#1619978 (10Esanders) 3NEW [09:28:19] 10VisualEditor, 10VisualEditor-MediaWiki: Copying MW extension nodes out of VE results in no rendering - https://phabricator.wikimedia.org/T111923#1619971 (10Esanders) [09:38:54] 10VisualEditor, 10VisualEditor-MediaWiki: Image paths inside generated extension nodes aren't absolutised when copied to the external clipboard - https://phabricator.wikimedia.org/T111927#1620023 (10Esanders) 3NEW [09:42:39] (03PS1) 10Esanders: Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) [09:44:58] (03CR) 10jenkins-bot: [V: 04-1] Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) (owner: 10Esanders) [09:58:17] 10VisualEditor, 10VisualEditor-MediaWiki: Image paths inside generated nodes (extension/template) aren't absolutised when copied to the external clipboard - https://phabricator.wikimedia.org/T111927#1620067 (10Esanders) [10:00:19] (03PS2) 10Esanders: Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) [10:02:21] (03CR) 10jenkins-bot: [V: 04-1] Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) (owner: 10Esanders) [10:09:12] (03PS1) 10Esanders: Resolve image paths when writing to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) [10:11:19] (03CR) 10jenkins-bot: [V: 04-1] Resolve image paths when writing to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) (owner: 10Esanders) [11:35:22] 10Citoid, 10VisualEditor, 10VisualEditor-MediaWiki-References, 7Design: Change label "Basic form" to something clearer - https://phabricator.wikimedia.org/T108713#1620354 (10Mvolz) [11:44:22] (03PS1) 10Esanders: Exclude citefromid and cite-(book,journal,...) commands from ref dialog [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237086 [12:02:41] 10Citoid, 7Easy: Strip whitespace out of openGraph fields - https://phabricator.wikimedia.org/T105805#1620417 (10Mvolz) [12:02:55] 10Citoid: Remove url parameters when getting DOI from URL - https://phabricator.wikimedia.org/T108832#1620418 (10Mvolz) [12:03:43] 10Citoid: Citoid identifies non-DOI URLs as DOIs - https://phabricator.wikimedia.org/T109536#1620420 (10Mvolz) [12:03:49] 10Citoid: Field abstract should be abstractNote - https://phabricator.wikimedia.org/T107444#1620421 (10Mvolz) [12:04:09] 10Citoid: http://www.example.com/10.1086/378695 returns citation with same author listed twice - https://phabricator.wikimedia.org/T109431#1620422 (10Mvolz) [15:19:45] 10VisualEditor: VE doesn't consistently clear element ids when content is copy-pasted across pages (leading to incorrect serialization of pasted content when it causes Parsoid to incorrectly use data-parsoid from the target page) - https://phabricator.wikimedia.org/T111312#1620902 (10GWicke) Copy & paste of enti... [15:34:09] 10VisualEditor, 10Parsoid, 10RESTBase: VE adds tags due to RB sending the wrong data-parsoid to Parsoid(?) - https://phabricator.wikimedia.org/T111491#1620953 (10GWicke) Note that it is possible that this might have been caused by T111312 as well. [15:46:16] 10VisualEditor: VE doesn't consistently clear element ids when content is copy-pasted across pages (leading to incorrect serialization of pasted content when it causes Parsoid to incorrectly use data-parsoid from the target page) - https://phabricator.wikimedia.org/T111312#1621041 (10ssastry) >>! In T111312#1620... [15:56:42] (03PS3) 10Jforrester: Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) (owner: 10Esanders) [16:13:21] 10VisualEditor, 6Analytics-Backlog, 10Analytics-Dashiki, 6Editing-Analysis, 5Patch-For-Review: Improve the edit analysis dashboard {lion} - https://phabricator.wikimedia.org/T104261#1621141 (10bmansurov) [16:13:25] edsanders|away: What do you think about us reaching "Code coverage reaches 80% overall, and over 90% in dm and over 70% in ce"? We're currently at 75.39%, 87.32% and 66.04% respectively. [16:19:19] (03PS2) 10Jforrester: Resolve image paths when writing to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) (owner: 10Esanders) [16:20:40] (03CR) 10Jforrester: "Hmm. Don't these URLs only exist for a brief period? Shouldn't we instead attach the image as a data-uri?" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) (owner: 10Esanders) [16:23:30] (03CR) 10Jforrester: [C: 032] Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) (owner: 10Esanders) [16:24:14] 10VisualEditor, 10VisualEditor-MediaWiki, 5Patch-For-Review: Copying MW extension nodes out of VE results in no rendering - https://phabricator.wikimedia.org/T111923#1621185 (10Jdforrester-WMF) 5Open>3Resolved p:5Triage>3Normal a:3Esanders [16:24:36] 10VisualEditor, 10VisualEditor-MediaWiki: MW extension node renderings not shown in reference preview - https://phabricator.wikimedia.org/T111924#1621194 (10Jdforrester-WMF) p:5Triage>3High a:3Esanders [16:24:45] 10VisualEditor, 10VisualEditor-MediaWiki: MW extension node renderings not shown in reference preview - https://phabricator.wikimedia.org/T111924#1621205 (10Jdforrester-WMF) 5Open>3Resolved [16:26:14] (03Merged) 10jenkins-bot: Use rendered contents when copying to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237067 (https://phabricator.wikimedia.org/T111923) (owner: 10Esanders) [16:35:41] (03CR) 10Jforrester: "This means you can't take a http://www.amazon.com, open it, cut the URL, paste into Citoid and turn into a {{cite web|…}}<" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237086 (owner: 10Esanders) [16:54:46] 1% is quite a lot [17:18:17] edsanders: Yes. [17:19:43] I think the goals were probably unrealistically high [17:20:49] Treading water on code coverage requires a decent amount of effort because we are constantly adding new code, some of which is really hard to test [17:21:30] so just "maintain or increase code coverage figures" would be a decent goal [17:23:58] * James_F nods. [17:24:11] I can reset the figures to above where we were at the start of the quarter. [17:25:59] 10VisualEditor: Some kind of filtering or security software inserts an HTML comment when editing with VisualEditor - https://phabricator.wikimedia.org/T111906#1621443 (10Krenair) [17:26:00] 10VisualEditor, 10VisualEditor-DataModel, 10VisualEditor-MediaWiki, 7Tracking: Broken browser plugins cause cruft to be injected into the page - https://phabricator.wikimedia.org/T54327#1621442 (10Krenair) [17:27:07] 10VisualEditor, 10VisualEditor-MediaWiki: Some kind of filtering or security software inserts an HTML comment when editing with VisualEditor - https://phabricator.wikimedia.org/T111906#1619638 (10Krenair) [17:31:22] James_F, yeah - are we up on the start of the Q? [17:34:51] edsanders: wmf12 (30 June) was 75.69% (so down 0.3%), 87.67% (so down 0.35%) and 66.11% (down 0.7%). [17:35:12] edsanders: We really need a CI tool that complains when code coverage goes down /cc Krinkle. [17:42:35] James_F: You could move to GitHub and use Travis and the coveralls bot to notify you on PRs :-) [17:42:44] I hear it works quite well [17:42:49] Krinkle: :-P [17:43:03] But they use a massive SaaS to store previosu results for comparison [17:43:13] along many different axis [17:43:34] You only need to store it for VE. [17:43:38] :P [17:43:39] I don't care about other repos. [17:43:40] ;-) [17:43:59] Yeah, but that's not an issue. It still needs a place that is accessible from slaves and what not [17:44:06] Doing it for one is as hard as doing it for all [17:44:08] git hash -> 1MB JSON blob isn't a huge storage need. [17:44:17] the space isn't the problem [17:44:22] Don't the slaves have network access? [17:44:23] it's the location and acess [17:44:26] (DMZ'ed) [17:44:32] and ability to push to that location [17:44:40] Why? [17:44:48] in post-merge [17:45:00] otherwise you keep comparing to last years result [17:45:02] Publish the .json in /cover/ [17:45:03] ;-) [17:45:27] 1234567889abcdef.json, etc. [17:45:32] James_F: That means the comparison goes against current atomic master instead of parent commit [17:45:50] Krinkle: I know. [17:45:58] Krinkle: But that's good enough for 95% of our patches. [17:46:06] Krinkle: And it gets us from nowhere to somewhere. [17:46:37] The other problem is that it requires logic specific to our infrastructure, so it needs to be fiddled into Jenkins outside the npm-test pipeline [17:46:45] "This patch (or its parent(s) if not off master) {de|in}creases coverage by X%." [17:47:02] and presumably skip the comparison in non-master branches [17:47:11] we can actually make it part of npm-test [17:47:19] you can fetch from int.wm.o locally too [17:47:25] Yeah. [17:47:35] that will keep it contained via a Grunt task [17:47:47] then we just need wmf-logic in the post-merge coverage publish job [17:47:52] okay, this is doable [17:47:55] give me 5 [17:48:09] So (a) add the JSON output to Gruntfile.js, (b) tweak coverage-publish to also push the JSON, (c) fetch and use it in a new task in Gruntfile.js [17:48:23] Krinkle: This is about VE-core BTW. [17:48:27] Krinkle: And you're awesome. [17:48:36] 5 million dollars and 5 years :P [17:48:41] Yeah yeah. [17:48:42] but let's hope 5 days [17:48:45] Psh. [17:48:48] Slacker. ;-) [17:49:00] I'll give it a shot over the weekend [17:49:01] soudns fun [19:31:58] (03PS2) 10Jforrester: TargetLoader: Use an OOUI MessageDialog, not window.alert() [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/224216 [19:32:05] (03PS3) 10Jforrester: TargetLoader: Use an OOUI MessageDialog, not window.alert() [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/224216 [19:34:12] (03CR) 10jenkins-bot: [V: 04-1] TargetLoader: Use an OOUI MessageDialog, not window.alert() [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/224216 (owner: 10Jforrester) [20:04:45] (03PS1) 10Jforrester: build: Output coverage-final.json from karma-coverage [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/237234 [20:23:26] 10VisualEditor, 7Epic: Negotiate Service Levels between VE and Stakeholders and identify underlying contradictory needs - https://phabricator.wikimedia.org/T102571#1622346 (10JAufrecht) [20:23:26] 10VisualEditor: Follow up on VE SLUs after the Engineering Offsite - https://phabricator.wikimedia.org/T111226#1622347 (10JAufrecht) [20:36:50] 10TemplateData: TemplateData: Add a way to express dependencies between parameters - https://phabricator.wikimedia.org/T52407#1622424 (10XanonymusX) Well, I have another case: In German Wikipedia we have Template:Charteintrag, where not only such dependencies are required (eg if “POS_xy” then also “WO_xy”), but... [20:43:12] (03CR) 10Alex Monk: [C: 032] Resolve image paths when writing to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) (owner: 10Esanders) [20:44:59] (03CR) 10Jforrester: "(I'd still like an answer to my semi-ish -1.)" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) (owner: 10Esanders) [20:45:40] (03Merged) 10jenkins-bot: Resolve image paths when writing to clipboard [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/237071 (https://phabricator.wikimedia.org/T111927) (owner: 10Esanders) [20:53:10] James_F, neilpquinn: re MF - "After you switch (action=abort), the next event is ready. Shouldn't we also send an init event for the new editor?" [20:56:56] Krenair: Hmm. Yes, the abort is also an init. [20:57:40] James_F: Thoughts on this? https://phabricator.wikimedia.org/T111598 [20:58:16] Deskana: Curious. [20:58:32] Deskana: Is Firefox doing a string-sort rather than a numeric sort or something unhelpful? [20:58:39] * James_F looks at Krenair guilt-inducingly. [21:09:56] Deskana, James_F: So Chrome is sorting template name suggestions one way and firefox another? [21:10:20] Krenair: Seems that way to me. The results are in a totally different order in Chrome from Firefox. [21:10:51] Krenair: The API return object has an index that might be being interpreted as numbers vs. strings between them, maybe? [21:11:11] Okay, I'll look into it [21:11:16] Krenair: Hmm. Yes, the abort is also an init. [21:11:23] Can we rely on people looking at the data to know this? [21:11:28] Yep, just reproduced it; works fine in Chrome, and badly in Firefox. [21:11:30] Crazy. [21:11:45] Krenair: Yes, I promise that I and neilpquinn will remember. [21:11:59] heh [21:12:06] In VE I'm pretty sure we'd abort on the VE page, then swap to another page and init there [21:12:13] Yes. [21:24:49] 10VisualEditor, 10VisualEditor-MediaWiki-Links, 10VisualEditor-MediaWiki-Templates, 7Browser-Support-Firefox: Firefox sorts API template (and other?) suggestions in a very poor manner, unlike Chrome/Safari/Opera - https://phabricator.wikimedia.org/T111598#1622619 (10Jdforrester-WMF) [21:24:56] 10VisualEditor, 10VisualEditor-MediaWiki-Links, 10VisualEditor-MediaWiki-Templates, 7Browser-Support-Firefox: Firefox sorts API template (and other?) suggestions in a very poor manner, unlike Chrome/Safari/Opera - https://phabricator.wikimedia.org/T111598#1611426 (10Jdforrester-WMF) a:5Deskana>3Krenair [21:27:00] James_F, Deskana: Well I can confirm that the lists are ordered differently in Chrome vs. FF on enwiki [21:27:32] Now I need to figure out how to reproduce the issue locally [21:27:40] Is it just A B C D E F G H I J -> J A B C D E F G H I? [21:27:47] Or is it a totally different sort? [21:50:32] is there a known issue in 1.25 with focus on the summary, when describing changes? [21:50:48] because i'm seeing one, and it's not nice. [21:53:50] I recall something to do with focus and edit summary [21:53:51] what is it? [21:55:09] James_F, I took the results of a query that I know was triggering different behaviour in FF from production [21:55:19] and made TitleInputWidget pretend that was what my local wiki sent [21:55:31] but both browsers sort it the same [21:55:43] juri_: In IE I think, but not other browsers? Maybe. [21:56:00] Krenair: Hmm. Maybe a gadget/script? [21:56:08] no [21:56:19] the focus appears to be stuck on the page being edited, not on the summary. [21:56:19] oh, wait. maybe. [21:56:24] will try beta [21:56:39] juri_: Yeah. [21:57:07] yeah, it's broken in enwiki beta [21:57:17] James_F: any plan to fix this in 1.25? [21:57:19] Krenair: Hmm. Curious. [21:57:20] okay, I can at least live hack to debug this without having to mess with production [21:57:38] juri_: No-one has worked out which commit broke it (and which made it work) so cherry-picking is hard. [21:57:44] juri_: Sorry. [21:58:01] James_F: need me to do that?.... [21:58:09] i need something that works. ;P [21:58:20] juri_: If you could that'd be amazing. [21:58:39] ok. on it. [21:58:51] Thanks. [22:02:49] ugh [22:02:54] I had forgotten debug mode was broken in beta [22:05:23] (03PS4) 10Jforrester: TargetLoader: Use an OOUI MessageDialog, not window.alert() [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/224216 [22:05:43] 10TemplateData: TemplateData help link target is not transated - https://phabricator.wikimedia.org/T112011#1622696 (10Ltrlg) 3NEW [22:07:51] 10TemplateData: TemplateData help link target is not transated - https://phabricator.wikimedia.org/T112011#1622709 (10Ltrlg) [22:11:04] James_F, so although the query results come back the same way in both browsers, they are ordered differently when you look at response.query.pages [22:11:31] properties order of objects is not guaranteed in JS [22:12:39] Chrome shows: Object {779: Object, 1272: Object, 1273: Object, 1274: Object} [22:12:47] FF shows: Object { 1272: Object, 1273: Object, 1274: Object, 779: Object } [22:18:40] We're not actually looking at the index values [22:23:28] urgh [22:23:34] and you have to take redirects into account [22:29:07] i can confirm that MW 1.25.2 + parsoid 5093392932358e4db26625b2f3627b007faffb9c + VE c1ed85403ea7ffdf2c75382c933cff0c6bac5139 + ULS 62ea28b1840a89a113d23186d5cd07c64caf49a4 is broken. [22:45:36] Oh, great [22:45:40] includes/api/ApiQueryPrefixSearch.php: $resultPageSet->setGeneratorData( $title, array( 'index' => $index + $offset + 1 ) ); [22:45:40] includes/api/ApiQuerySearch.php: $resultPageSet->setGeneratorData( $title, array( 'index' => $index + $offset ) ); [22:48:13] Oh, except they're not actually incompatible, ApiQuerySearch adds 1 to $offset when setting it instead [22:49:30] Still... how to implement support for this in mw.widgets.TitleInputWidget.prototype.getLookupMenuOptionsFromData so it can handle both modules which do and modules which don't set this [22:49:57] if [ index ] ? [22:50:30] You can't just check the first one or whatever. [22:50:39] Because these modules don't guarantee it'll get set. [22:51:07] In the case of Template:Cn -> Template:Citation_needed, for example, it sets the index on the redirect object instead of the page object [22:51:14] Oh. [22:51:17] * James_F sighs. [22:51:18] http://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&format=jsonfm&generator=prefixsearch&gpssearch=cn&gpsnamespace=10&gpslimit=10&ppprop=disambiguation&redirects=1&prop=info%7Cpageprops [22:51:35] Can we intercept the api.php result and replace it with an actual array? [22:51:46] pleaseMakeAPIUseful() [22:52:42] I guess maybe you could make mw.widgets.TitleInputWidget.prototype.getLookupMenuOptionsFromData support response.pages being either an array or an object [22:53:13] and then in code handling prefixsearch/search, convert it all to an array indexed according to the 'index' variables [22:53:28] er, keys [22:55:16] Yeah. [23:08:15] (03CR) 10Jforrester: [C: 04-1] "Still has the issue with the cartouche / tool status being out of sync." [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/217257 (https://phabricator.wikimedia.org/T91285) (owner: 10Divec) [23:57:01] 10VisualEditor, 6Editing-Department, 10Gallery, 6Multimedia: Make enwiki's Template:Gallery redundant by implementing all its features in wikitext - https://phabricator.wikimedia.org/T95531#1623214 (10Jdforrester-WMF)