[04:38:42] greg-g: legoktm as part of mwpt [04:39:02] also I'm not sure if we're still MWPT? [04:40:06] Krinkle: IIRC golang's regexes (not pcre) does not support negative matches [13:23:11] paladox: Another PolyGerrit bug for you: In the old UI's search box, if I type "project:mediawiki/extensions/Scr" the autocompletion dropdown shows results. In the new UI it doesn't. [13:23:56] paladox: Actually, the same happens for "project:mediawiki/extensions/A" even though it shows results beginning with "A" if the "A" is left off. I think it might be mistakenly assuming projects are all-lowercase. [13:25:32] paladox: It seems that gerrit-test and gerrit-new probably don't have the bug, although it's a little hard to be sure since they have different sets of projects. [14:04:05] anomie: someone else reported that bug [14:04:06] On phab [14:04:42] anomie: https://phabricator.wikimedia.org/T188842 [14:04:48] That is fixed in 2.15+ [14:15:33] anomie: also upstream are going to be removing gwtui from gerrit-review starting may 18 2018 [14:15:53] Not sure if that will include its removal from core, but would most likely be removed quickly after [14:16:25] https://docs.google.com/document/d/1_11Y79_MgHqO1G0f8N6LSsogAEj6vv6wep7DZk2c8gY/mobilebasic [16:45:44] Curious if anyone knows yet about https://phabricator.wikimedia.org/T187147 [16:46:01] (to, or not to; mediawiki/php/wmerrors for PHP7) [18:15:52] Reedy, Krinkle: This is the sanest channel you're both in re. frwikiquote. [18:16:12] James_F: is or might? [18:16:28] They're not removed. [18:16:35] The browser still has 'em. [18:16:46] Is. Most pages are unpainting to a blank HTML document once JS executes. [18:16:51] If called before document ready, they work normally, and will work better than before. [18:17:53] If called from an async script, the normal browser behaviour will happen, which is to ignore the call (per the W3C spec). To prevent those silent ignores, we had a wikibits-appendix that stubs out the native method with our own that sort of parses it and append to document.body. [18:18:18] That's not gonna happen anymore, but nothing wil break, other than some 10 year old code now becoming a no-op, which seems clean? [18:18:21] Then I'm not sure what to blame. :-( [18:18:33] The current behaviour is a UBN though. [18:18:36] And there will still be a deprecation notice, even. From the browser itself instead of us. [18:18:46] Task? [18:18:48] Details? [18:18:57] No task filed as of yet [18:19:04] Visit https://fr.wikiquote.org/wiki/Wikiquote:Accueil twice in a row [18:19:06] First will be fine [18:19:07] Not yet filed. See #-tech complaint. [18:19:08] Second ends up white [18:19:15] Turn off js. fine. Safemode, fine [18:19:24] Change skin, ok for first visit again [18:20:24] Ends up with etc etc [18:20:30] OK. I see it now, looking [18:20:41] Cheers [18:21:24] Filed as https://phabricator.wikimedia.org/T193191 [18:21:29] Thx [18:22:11] Without knowing how many wikis are impacted, we may want to rollback for a few hours. [18:22:29] Or revert the patch in-branch for now. [18:22:40] I dont' know what's going, but I can tell that yes, reverting it would fix it. [18:22:49] Possibly a browser or separate RL bug. [18:22:53] :-( [18:22:59] the reason it happens only on second load is because that time it comes from localStorage/eval [18:23:03] instead of async script [18:23:17] If it was a bigger issue, I'm sure peple would've been screaming already [18:23:24] which should behave the same way (given it's a rIC'ed eval from an async script), but apparently doesn't. [18:23:41] Probably a bug in Chrome, and whatever other browsers are affected. [18:24:18] Krinkle: Revert for master in https://gerrit.wikimedia.org/r/#/c/429248/ [19:13:25] It seems there's 2 writeln [19:13:57] Potentially 900+ writes [19:14:05] though, that's likely a false positive [19:16:45] write in user [19:16:46] (total: 29217, shown: 1000) [19:21:51] Krinkle, Reedy: So… are we reverting? Mass-commenting-out MW: pages? [19:23:24] Revert out of .1 for now, and work out? [19:23:36] Presumably this should be find-and-replace-able [19:24:05] Chad just merged your .1 cherry pick [19:24:45] So I see. [19:25:54] Reedy: s/document.write(…)/$( 'body' ).append( $.parseHTML( $1 ) ? [19:26:14] You're missing at least a ) [19:26:46] Hmm [19:26:50] If it is document.write... [19:26:54] Yeah, well, it's not like I have a regex-capable bot. [19:26:54] (total: 147, shown: 100) [19:27:12] (total: 26491, shown: 100) [19:27:17] Userspace is gonna be the clusterfuck [19:27:44] That's user scripts. [19:28:14] But if they'll break stuff in the same way :) [19:28:36] But not for readers who can't do anything about it, unlike site scripts or default gadgets. [19:28:44] Which is more than we officially support anyway. [19:31:30] It'd be interesting to know which are used [19:31:34] https://scn.wikipedia.org/w/index.php?title=MediaWiki:Gadget-Monobook.js&action=history [19:31:45] Krenair last touched, a year ago... After nothing for 9 years [19:34:07] In thats case... [19:34:08] https://scn.wikipedia.org/wiki/Spiciali:Accessori [19:34:22] It's seemingly not even loaded [19:34:38] Beautiful. :-( [19:34:51] annoyingly, wikigrep doesn't have a wiki argument [19:35:29] "wikigrep … | grep enwiki" [19:35:48] yup [19:36:24] Because half our scripts are one-and-done and half are UNIX-it's-all-just-pipes [19:36:32] Yup [19:36:34] That page is orphaned [19:36:50] No references in user or MediaWiki [19:37:00] Should we just delete it? SuSA would probably shout at us. [19:37:06] "MediaWiki:Gadget-Monobook.js" has been deleted. See deletion log for a record of recent deletions. [19:37:07] Oh well [19:37:14] If someone really needs it, they can restore it [19:37:31] * James_F tsks. :-) [19:37:38] One done, 200 to go? [19:38:00] If some are jquery-ified they're easier to fix [19:38:05] But stuff like that is soooo rotted [19:38:31] canhasglobalprefs [19:38:37] Keep having to set en [19:39:02] My general feeling is that all MW:-space pages should auto-delete after 12 months unless a local sysop manually confirms that the over-ride/gadget/etc. is still actively needed. [19:39:35] https://ur.wikipedia.org/w/index.php?title=%D9%85%DB%8C%DA%88%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:UrduEditor.js&action=history [19:39:41] Another not touched in 10+ years [19:42:13] reedy@tin:~$ mwgrep UrduEditor [19:42:13] urwiki MediaWiki:UrduEditor.js [19:42:13] (total: 1, shown: 1) [19:42:13] reedy@tin:~$ mwgrep UrduEditor --user [19:42:13] urwiki User:Qamar Ansari/monobook.js [19:42:15] (total: 1, shown: 1) [19:42:23] Actually seemingly used by someone [19:42:28] But they're not necessarily active [19:44:08] * James_F fixed the reported site with https://fr.wikiquote.org/w/index.php?title=MediaWiki:Common.js&diff=263727&oldid=256489 [19:46:22] Part of me wonders if we just wait for people to complain? :P [19:47:06] Reedy: My favourite thing for mwgrep would be for files loaded by default to be flagged. Site scripts and default gadgets are very different from some reference in a comment on an unlinked, unused page. :-) [19:47:20] Getting patches merged into that is crap [19:47:30] I'm still waiting for my "hide private sites" thing to be... [19:47:33] Well, no_justification has reverted the patch for this week's train. We could just let it linger for next week with a quick note in Tech/News? [19:48:01] I'd review it for you, but given I don't even have access to use the tool I can't reasonably test it, can I? :-) [19:48:15] don't you have sheall access? [19:48:53] Oh [19:48:53] Wait [19:48:55] Only to stats. [19:48:55] It did get merged [19:48:56] xD [19:48:56] --no-private Restricts search to public wikis [19:49:03] Ha. [19:49:11] Pretty sure that took a long time [19:50:20] Yup, took 20-21 months [19:50:47] https://gerrit.wikimedia.org/r/#/c/262068/ [19:50:48] :P [19:51:18] Ouch. [19:53:53] James_F: More like s/document.write(..)//, or comment ing out. Converting to append() would be a mistake imho. [19:54:21] It should be looked at by someone who knows what it is supposed to be doing and can verify that whatever "it" is meant to do actually worked currently and can continue to work. [19:54:34] Most of it is dead, and I'd always prefer a silent no-op followed by removal as default. [19:54:48] Fair. [19:55:24] For wikibits, we first deprecated it with warnings for 2 years, then silent no-ops with warnings for 3 years, and then removed it. At which point removing it was an improvement over a fatal error. [19:55:37] and it was already not doing anything :) [19:55:45] Maybe we could hack RL to refuse to load any code file with a document.write[ln] in it? The problem would go from "the site is broken" to "the site doesn't load Common.js". [19:55:45] comment out all the things [19:56:12] document.writel and document.writen ? :P [19:56:23] Yeah, my version of that is, to next week: Update the stub to not append, but just no-op. Then after a few months, remove it again, and comment them out with a bot if still remaining. [19:56:26] Yeah yeah. [19:56:51] Krinkle: Or run the bot now? They've sat untouched for a decade. They're not going to suddenly get fixed. [19:57:04] Well, they've been working for a decade. [19:57:05] Change the deprecation to alert( 'Stop using document.write already!' ) ;) [19:57:28] lol [19:57:48] I definitely saw a drop in usage after we made them no-ops. 90% of it was already dead, but some of it did do something useful, people noticed, and them reached out to help get it fixed/impoved/find maintainers. [19:57:54] No no, just do $( 'body' ).css( 'color: red' ); [19:58:04] Or accept that unmaintained for 10 years means it'll get disabled, which is fair. [19:58:10] Let's not :P [19:58:18] It'd get noticed. :-) [19:58:22] I've reproduced the bug in Chrome and Firefox btw [19:58:22] https://codepen.io/Krinkle/pen/pVjORL/ [19:58:26] I'll report later. [19:58:34] Loks like their 'async script' detection needs some work. [19:58:58] * James_F grins. [19:59:28] also, when you blank the page with document.write(), you can get very funny bugs with navigation timing and performance. [19:59:32] because its logically a new document. [19:59:41] e.g. document.body from before !== document.body from now [20:00:08] Krinkle: My preference would be to leave the removal in for wmf.2 and onwards, and put a quick note in Tech/News, rather than dragging this out for yet longer. [20:00:30] I made the mistake of assuming the old nodes would get detached and (if you stll have a reference) have .parentNode=null, but they actually preserve the whole thing. The whole document remains in tact, but headless. [20:00:52] so it's not like document.documentElement = ''. It's more like document = new Document().open [20:00:59] anyway [20:01:02] bbl [20:18:20] [{exception_id}] {exception_url} BadMethodCallException from line 299 of /srv/mediawiki/php-1.32.0-wmf.1/extensions/TwoColConflict/includes/InlineTwoColConflict/InlineTwoColConflictHelper.php: Call to a member function getUser() on a non-object (null) [20:19:34] $out .= Linker::userLink( $currentRev->getUser(), $currentRev->getUserText() ); [20:19:44] getRevision.. * @return Revision|null [20:21:51] addshore: Y U WRITE BROKEN CODEZ [20:32:43] THEY ALL BORKED [20:33:15] MediaWiki doesn't ever work, it's all our imagination [22:48:28] Reedy: While I'm thinking about it, why not move mail to required? [22:49:03] could do, yeah [22:49:19] There's been a vague todo of removing pear mail stuff from the app servers [22:50:01] If we just rely on the vendor one and stop doing require() calls then we can do that $whenever [22:52:04] Tho, that brings in the whole of Pear. [22:52:07] Maybe not move to required [22:52:13] But still, can drop the Pear version [22:52:49] don't we just do like we did in vendor? [22:53:03] explicitly define pear/pear-core-minimal [22:53:22] "pear/console_getopt": "1.4.1", [22:53:22] "pear/mail": "1.4.1", [22:53:22] "pear/mail_mime": "1.10.2", [22:53:22] "pear/mail_mime-decode": "", [22:53:22] "pear/net_smtp": "1.7.3", [22:53:23] "pear/net_socket": "1.2.1", [22:53:25] "pear/pear-core-minimal": "1.10.3", [22:53:28] "pear/pear_exception": "1.0.0", [22:56:23] Yeah, just feels gross to add all of pear for an optional feature [23:34:18] legoktm: Seems phan is being run on older branches of extensions.. and failing due to no phan config [23:34:22] https://integration.wikimedia.org/ci/job/mwext-php70-phan-docker/5471/console [23:34:44] Shall I file a task? :P [23:41:58] https://gerrit.wikimedia.org/r/#/c/429365/ [23:48:54] 23:47:30 ERROR: Zuul jobs are defined by JJB [23:48:56] wat [23:49:11] 23:47:30 MultipleInvalid: extra keys not allowed @ data['projects'][1241]['template']['branch'] [23:49:51] I see :( [23:50:06] Reedy: I guess we can use skip-if for extensions where it's annoying [23:50:37] it probably affects a bunch of extensions [23:50:52] legoktm: https://phabricator.wikimedia.org/T193212#4163053 [23:51:01] Would be my naieve grep that could potentially be affected [23:51:19] Ah [23:51:42] I wonder if we could have the job check for the existence of tests/phan/config.php, and bail if it doesn't exist [23:53:31] bet we can [23:54:28] just still a -f in mwext-php70-phan-docker's shell? [23:55:08] we need the job to exit status 0 if it doesn't exist, or the result of phan if it does [23:55:09] https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/jjb/mediawiki-extensions.yaml#370 [23:55:38] yeah, that's what I was looking at [23:58:29] legoktm: https://gerrit.wikimedia.org/r/#/c/429367/ [23:58:46] Might need an extra leading / there I guess [23:59:21] I don't think $ZUUL_PROJECT is part of path [23:59:28] it should be src/extensions/Foo