[14:11:33] Bugfix: How can I see when one is getting into the version Wikipedia's running? I'm guessing Wikipedia runs latest stable (1.37.0-wmf.20 looks like), but the bug in mind was closed 3 years ago, between 1.30 and 1.31. The fix works on https://en.m.wikipedia.beta.wmflabs.org/ - Bug in question: https://phabricator.wikimedia.org/T190939 [14:20:34] Grems: 1.37 is alpha not stable [14:21:18] I can't reproduce though [14:21:28] It works for me [14:27:29] On https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/422445 [14:27:32] It says it's in 1.31 onwards [14:46:28] RhinosF1: ("1.37.0-wmf.20" is taken from view-source of a Wikipedia page) [14:46:49] Hm. I can still reproduce on Wikipedia [14:46:58] Grems: yes that's an alpha release not stable [14:47:12] Example: https://en.m.wikipedia.org/w/index.php?search=cattttt&ns0=1#/search [14:47:24] Correction: https://en.m.wikipedia.org/w/index.php?search=cattttt&ns0=1 [14:47:40] Ah [14:48:05] That's not the issue the bug describes [14:48:08] 1.31 was what I thought, with the tag there. But then surprised that I can still reproduce [14:48:12] I see [14:48:18] The bug describes when clicking the magnifying glass [14:48:26] The bug was linked to from a different issue. My mistake [14:48:34] You're looking at directly on the Special:Search page [14:49:09] Which is blank in desktop too https://en.wikipedia.org/wiki/Special:Search [14:49:27] If you click the magnifying glass do you see the text [14:49:57] Grems: ^ [14:50:07] Reedy: do I make sense [14:51:29] Hm. I think the issue I'm having might not have been communicated in this chat so far [14:52:06] tl;dr: I want "cattttt" to be modifiable in the en.m.wikipedia-search linked to above [14:52:21] I have a list of issues which might be that very issue. I'll go through them [14:52:37] I can type quite easily in search box [14:52:44] But that's definately not the task you linked [14:53:10] You can type, but can you modify "cattttt", or does it blank? [14:53:16] blanks for me [14:53:26] I can modify [14:53:48] what browser are you running? [14:54:01] Chrome for iOS [14:54:18] Grems how about you? what browser? [14:54:40] Firefox on Linux [14:54:55] https://usercontent.irccloud-cdn.com/file/a3dRkfbZ/trim.1653D033-382B-433A-B36C-4A9C962FDD85.mp4 [14:54:59] (Note: en.*m*.wikipedia, not en.wikipedia) [14:55:00] Grems: ^ [14:55:09] Safari on iOS too works [14:55:33] Well, well, well. That's progress at least [14:55:34] was able to repro on Firefox/Windows so seems like this may be a firefox-specific issue [14:55:44] That's a start [14:55:48] Last time I busied myself with this I could reproduce with Firefox on Android [14:56:10] moonmoon, Grems: can you reproduce on any non firefox based browser [14:56:22] Also can you take a screen video showing [14:56:43] Testing… [14:57:14] Yes. Ungoogled Chromium [14:57:26] Weird [15:00:12] I think this is related: https://phabricator.wikimedia.org/T43039 [15:00:50] ("Cannot select search results Opera Mobile") [15:02:19] Nevermind. Not as related as I thought [15:02:29] No [15:02:32] Definately not [15:02:38] I think it's worth a new bug [15:06:14] I'm confused as to why this works on any browser tbh now that I found the code in question [15:06:27] Code link? [15:07:17] it's a bug with the MobileFrontend extension [15:07:30] the skin passes the search input to the extension, which promptly does absolutely nothing with it [15:07:52] Grems: if I make a patch would you be willing to test it out? [15:07:58] Yes [15:09:45] k give me a bit [15:30:31] Grems: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/715982 [15:30:44] completely untested as of right now, so your input would be appreciated :) [15:32:24] Testing… [15:33:49] moonmoon: Well. If I knew how. How do I test this? :) [15:34:04] did you download MobileFrontend via git or via a tarball? [15:34:20] Neither. Git-cloning now [15:34:41] oh you don't have a local wiki where this was running? [15:34:57] Correct [15:35:11] testing is going to be an Adventure(tm) then :P [15:35:19] (you need a fully working mediawiki install) [15:35:23] Oh boy [15:35:35] I'll see if I can get legoktm to deploy it to the beta cluster instead [15:35:43] :) [15:35:52] o.O [15:35:57] hi :) [15:36:40] although should wait for jenkins to V+2 first [15:37:21] legoktm: testing a bugfix for MobileFrontend, and I don't have a test wiki to deploy on atm (away from primary dev computer) :< [15:37:27] https://github.com/rlewkowicz/docker-mediawiki-stack might help for the local install [15:37:34] have you tried patchdemo? [15:37:41] idk what patchdemo is [15:38:04] it sets up a temporary wiki with your Gerrit patch pulled onto it https://patchdemo.wmflabs.org/ [15:38:14] neat! [15:38:17] does that work for extensions? [15:38:44] yep [15:39:32] creating one now... [15:40:01] looks like yes [15:40:03] oh I just did too [15:40:04] woops [15:41:12] :P [15:41:31] https://patchdemo.wmflabs.org/wikis/fa332b423c/wiki/Main_Page [15:41:51] doesn't seem to work :( [15:42:04] and I don't have time right now to investigate [15:42:15] works for me [15:42:19] well that is a neat tool that needs to be promoted more [15:42:43] yeah I didn't know it existed, it's pretty amazing [15:42:57] jimman2003: sorry I meant my patch doesn't seem to work [15:42:59] so what exactly is broken? the top bar search overlay present on all pages should get the term pre-filled from Special:Search? [15:43:13] right [15:43:33] (if such a term exists) [15:55:13] patchdemo is my clear favorite for the next round of Coolest Tool Award [16:23:42] moonmoon: Patch seems to work in 2 browsers here. :) [16:25:18] Wait. Now this one doesn't seem to work after all [16:32:14] Patch works in Firefox Desktop for me, but not in Ungoogled Chromium Desktop [23:55:18] DannyS712: Perhaps you can give mw.loader.store another look? I believe my thinking of it needing to remain publicly writable is slightly more flexible than I remember. The idea is that, if you have `var store = {};` and then `store.foo()` and `mw.loader.store` then when a test later tries to change `mw.loader.store`, it does not do anything since that would re-assign the loader property, instead of the store variable which would continue [23:55:18] pointing to the same object. [23:55:38] However, all our mocking for mw.loader.store happens only at the sub-property level, thus this problem does not happen. [23:55:47] I can elaborate, but let me know if this makes sense so far.