Page MenuHomePhabricator

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

Assigned To
Authored By
Jdlrobson
Aug 3 2020, 10:02 PM
Referenced Files
F31963436: image.png
Aug 4 2020, 9:12 PM
F31963440: image.png
Aug 4 2020, 9:12 PM
F31963071: Rad_Mobile_game_screenshot.png
Aug 4 2020, 2:24 PM
F31962805: image.png
Aug 4 2020, 8:42 AM
F31962377: image.png
Aug 3 2020, 11:23 PM
F31962373: image.png
Aug 3 2020, 11:19 PM
F31962333: Screen Shot 2020-08-03 at 2.57.15 PM.png
Aug 3 2020, 10:02 PM
Tokens
"Like" token, awarded by Tony-smith."Cup of Joe" token, awarded by Rachmat04."Like" token, awarded by Streetdeck.

Description

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

https://en.m.wikipedia.org/wiki/Battle_of_Trenton

Screen Shot 2020-08-03 at 2.57.15 PM.png (578×1 px, 240 KB)

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
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.

+ 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>。

+ 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).

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

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.

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

image.png (768×1 px, 186 KB)

image.png (142×931 px, 15 KB)

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.

@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.

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

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.

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.