Tasks related to JavaScript in MediaWiki core or extensions.
See also Instrument-ClientError (Javascript error logging in Wikimedia production).
Tasks related to JavaScript in MediaWiki core or extensions.
See also Instrument-ClientError (Javascript error logging in Wikimedia production).
I can replicate on https://bn.m.wikivoyage.org/wiki/%E0%A6%89%E0%A6%87%E0%A6%95%E0%A6%BF%E0%A6%AD%E0%A7%8D%E0%A6%B0%E0%A6%AE%E0%A6%A3:%E0%A6%A8%E0%A6%BF%E0%A6%AC%E0%A6%A8%E0%A7%8D%E0%A6%A7_%E0%A6%AA%E0%A7%8D%E0%A6%B0%E0%A6%A4%E0%A6%BF%E0%A6%AF%E0%A7%8B%E0%A6%97%E0%A6%BF%E0%A6%A4%E0%A6%BE_%E0%A7%A8%E0%A7%A6%E0%A7%A8%E0%A7%AA/%E0%A6%A8%E0%A6%BF%E0%A6%AC%E0%A6%A8%E0%A7%8D%E0%A6%A7_%E0%A6%A4%E0%A6%BE%E0%A6%B2%E0%A6%BF%E0%A6%95%E0%A6%BE - I can look into the associated gadget later and suggest a fix.
This is still occurring at a significant rante - mostly on bn.m.wikivoyage.org and en.m.wikivoyage.org
so I assume a gadget there also needs to be updated.
We did it for PHPUnit tests as reflected on https://doc.wikimedia.org/cover-extensions/ .
Change #1081448 merged by jenkins-bot:
[mediawiki/core@master] Simplify code to avoid interpreting "$" characters in string replacement
I took the opportunity to replace the other occurrence in mediawiki/core.
That's neat, I like it.
Change #1081448 had a related patch set uploaded (by Gerrit Patch Uploader; author: Anne Haunime):
[mediawiki/core@master] Simplify code to avoid interpreting "$" characters in string replacement
Change #1080320 merged by jenkins-bot:
[mediawiki/core@master] live preview: Do not add edit/view-source link for special pages
Change #1080323 merged by jenkins-bot:
[mediawiki/core@master] TemplatesOnThisPage: Do not show non-functional link for special pages
I couldn't reproduce this at first – special page transclusion does not result in those links being shown. I eventually figured out that the links are produced by Scribunto's mw.title getContent() method. I think that's the real bug here, and I filed a task about it: T377530: Scribunto mw.title getContent() method can record templatelinks to special pages (but I still approved your patches here, as it seems reasonable to handle this case – maybe recording special page transclusions is made to work one day, or maybe no one ever fixes that Scribunto bug).
Thanks Od1n, very appreciated, I should do that for my local wiki also sometime. There are still some remaining extensions and I've got busy with some other things but overall this went well I think. Thanks
Change #1069544 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] build: Updating npm dependencies
I have removed all uses on frwiki (I handled the remaining cases I mentioned above) and on frwiktionary (there was only one occurrence).
Change #1080323 had a related patch set uploaded (by Ammarpad; author: Ammarpad):
[mediawiki/core@master] TemplatesOnThisPage: Do not show non-functional link for special pages
I think we also need to duplicate this for the non-live preview version. There's no error in that case, but a non-functional 'view-soure' link is always shown.
Change #1080320 had a related patch set uploaded (by Ammarpad; author: Ammarpad):
[mediawiki/core@master] live preview: Do not add edit/view-source link for special pages
Change #1071846 merged by jenkins-bot:
[mediawiki/extensions/MultimediaViewer@master] Use browser provided URL object instead of mw.Uri
Change #1074726 merged by jenkins-bot:
[mediawiki/extensions/TocTree@master] Use ES6 features
In T40932#10221678, @SD0001 wrote:Note that this feature isn't Parsoid-DOM compatible (compare https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=0 and https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=1)
I see ext.pygments.view is not being loaded in Parsoid DOM, even though we are adding the module to ParserOutput via the parser hook. I guess something else needs to be done for Parsoid compatibility?
I have removed the majority of uses of "mw.Uri" on frwiki.
Change #1078975 merged by jenkins-bot:
[mediawiki/extensions/SyntaxHighlight_GeSHi@master] Fix styling for code blocks with copy buttons next to floated content
Note that this feature isn't Parsoid-DOM compatible (compare https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=0 and https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=1)
Ok, thanks to getAll() it can be achieved, just a very tiny bit less conveniently:
In T374314#10129809, @matmarex wrote:Also, worth noting that mw.Uri and URL treat duplicate query parameters when parsing differently.
uri = new mw.Uri('http://example.com/foo?a=1&a=2') uri.query.a // => [ "1", "2" ] uri = new mw.Uri('http://example.com/foo?a=1&a=2', {arrayParams: true}) uri.query.a // => "2" url = new URL('http://example.com/foo?a=1&a=2') url.searchParams.get('a') // => "1" url.searchParams.getAll('a') // => [ "1", "2" ]
Change #1069544 had a related patch set uploaded (by Jforrester; author: Libraryupgrader):
[mediawiki/extensions/Kartographer@master] build: Updating npm dependencies
Just slam _addItem into "allowedGlobals": [] in the jsdoc.json and it'll work fine.
Any new insights? If createEntityView in wikibase.ui.entityViewInit.js shall not be called from commonswiki, maybe we should simply return from this function if mw.config.get('wgWikiID') === 'commonswiki' && mw.config.get( 'wgCanonicalNamespace' ) === 'File'