Page MenuHomePhabricator

[Regression] Unparsed wikitext in various JavaScript messages
Closed, ResolvedPublic


NOTE: The non-public cause of this is known and is being worked on.

This bug now tracks all issues with unparsed wikitext appearing in the interface in a variety of places.

Original issue

I can't replicate this locally but it seems to be occurring across the wiki.

Developer notes

Following works fines:

 mw.messages.set('test1', '[[Special:Block]] $1.' );
mw.message( 'test1', 'test' ).parse();

The following doesn't:

mw.messages.set('test1', '[$1 a]' );
mw.message( 'test1', 'test' ).parse();

The following does

mw.messages.set('test1', 'a [https://foo A]' );
mw.message( 'test1', 'test' ).parse();

The following doesn't work on production but does locally:

mw.messages.set('test1', 'a [$1 A]' );
mw.message( 'test1', '/wiki/Foo' ).parse();

Under the hood this message uses mw.util getUrl - I'm not sure if previously that returned an absolute URI but it appeared to return a relative URI.
Technically [/wiki/Foo test] is invalid wikitext so it makes sense this is failing but it's not clear what has changed to cause this and break this in production.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
cscott added a comment.EditedAug 4 2020, 3:36 AM

I don't think that [/wiki/... foo] should "ever" have worked. That's not valid wikitext. Anything which uses the mw.api.parse() method will dispatch through the action=parse endpoint of the action API, which is the canonical parser, and fail to parse that construct. That hasn't changed for a long time, and [/wiki/... ] has always been invalid wikitext.

One avenue is to figure out why/how you're getting a relative URL there instead of an absolute or protocol-relative URL. mediawiki.util.getUrl explicitly says it returns a link "relative to wgServer" and that hasn't changed for a long time either. It uses mw.config.get('wgArticlePath') and mw.config.get("wgScript") and mw.config.get("wgScriptPath"), all of which should be relative URLs.

It appears that mediawiki.jqueryMsg might be doing something fancy though (as @Jdlrobson pointed out above). If that fancy thing is something other than "eventually dispatching via mw.api.parse() to render wikitext" then all bets are off.

EDIT: I have found mediawiki.jqueryMsg.peg. All bets are off. (And I have another pseudo-wikitext parser to add to my collection!)

Ammarpad renamed this task from [Regression] Last modified bar is showing wikitext and history page inaccessible, JavaScript messages with relative links in wikitext cannot be parsed to [Regression] Unparsed wikitext in various JavaScript messages.Aug 4 2020, 4:04 AM

The non-public cause of this is known and is being worked on.

Ammarpad updated the task description. (Show Details)Aug 4 2020, 4:08 AM

+ File:Screenshot 20200804-073930 ZEM.jpg

+ File:Screenshot 20200804-073930 ZEM.jpg

I can't view this image, so please re-upload it.

It also don't work at flow talk pages. Like: [[zh:Wp:ASK]],it's a flow talk page. Using source code editor, it shows:

Wiki文本<a title="mw:Special:MyLanguage/Help:Formatting" href="/wiki/mw:Special:MyLanguage/Help:Formatting" target="_blank">使用标记语法</a>,当然您也可以随时<a href="#" class="flow-ui-editorWidget-label-preview">预览结果</a>。

Like this image.

+ File:Screenshot 20200804-073930 ZEM.jpg

I can't view this image, so please re-upload it.

It should be this Commons image (not sure if it needs to be uploaded here).

Mentioned in SAL (#wikimedia-operations) [2020-08-04T11:12:39Z] <Lucas_WMDE> Deployed patch for T86738 / T259565

This should be fixed now.

It now seems fixed on my end.

Rachmat04 removed a subscriber: Rachmat04.

True, the Flow issue still exists. The non-public cause for this is also known and being worked on.

Jdlrobson closed this task as Resolved.Aug 4 2020, 3:29 PM
Jdlrobson claimed this task.

Thanks for the quick turnaround. Minerva is indeed fixed. @cscott I agree this shouldn't use relative URIs so I've created T259628 to take care of that.

Daimona added a subscriber: Daimona.Aug 4 2020, 4:50 PM

Look, in the wikipedia content translation page, the link of the published translation not showing correctly, it is shown as wikitext

Who added "Resolved" tag? It's not resolved, it's still happening at Flow talk pages and translate pages (like RodneyAraujo said) maybe will more. I suggest to restore MediaWiki software to last version. It is happening over all WMF sites.

Jdlrobson added a comment.EditedAug 5 2020, 1:34 AM

@Clover_Yan this particular issue is about the mobile last modified bar which is now fixed. There is another private task tracking the larger error with security implications at T86738. That remains open.

+ File:Screenshot 20200804-073930 ZEM.jpg

I can't view this image, so please re-upload it.

this file is on wikimedia commons.

Jdlrobson updated the task description. (Show Details)
Jdlrobson removed a project: Security.

Since this is being used as a generic task now I'm going to reopen, untag and mute since it seems there is value in having a public task.

Jdlrobson reopened this task as Open.Aug 5 2020, 2:49 PM
Jdlrobson added a project: Security-Team.

I've removed Parsing-Team--ARCHIVED since we're not involved in the fix here.

sbassett moved this task from Incoming to Watching on the Security-Team board.Aug 5 2020, 4:08 PM

This task has been reopened. Is this fixed?

The Flow and ContentTranslation issues should be fixed on wmf.3 now (but that’s currently only deployed to group0, see T257971). I’m not aware of any other issues.

Lucas_Werkmeister_WMDE closed this task as Resolved.Aug 10 2020, 9:59 AM

wmf.3 has been deployed to all wikis now, so all the known issues should be resolved at this point. If there are any more, please reopen.