List of steps to reproduce
- Create an empty mass-message delivery list via Special:ChangeContentModel anywhere on the wiki (I used User:Martin Urbanec/Massmessage bug to reproduce)
- Go to the newly-created delivery list
- Add any user talk page to the delivery list
- Refresh the page
See screencast at https://commons.wikimedia.org/wiki/File:Screencast_reproducing_a_massmessage_bug_--_T299896.webm.
What happens?:
The page is empty.
What should have happened instead?:
Editing interface should be shown, like the one below (copied from https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Empty1):
Early investigation notes
I'm 95% sure this is what's happening:
- After user adds a user talk page to the delivery list, MassMessage's MassMessageListContentHandler::fillParserOutput is called in a way that makes $cpoParams->getGenerateHtml() return false.
- Because of the if at line 219 and else branch at line 238, MassMessageListContentHandler::fillParserOutput returns an empty HTML for this call.
- This empty HTML is saved into the parser cache for the revision in question
- No actual parsing happens when the user refreshes the page (steps reproduce, point 4); parser cache is consulted, returns an empty (but otherwise valid) HTML and this response is sent to the user.
This is supported by my shell.php fiddling in production:
>>> $page = \MediaWiki\MediaWikiServices::getInstance()->getWikiPageFactory()->newFromTitle(Title::newFromText('User:Martin Urbanec/Massmessage bug'))
=> WikiPage {#3277
mTitle: Title {#3266
mArticleID: -1,
prefixedText: null,
mDefaultNamespace: 0,
mRedirect: null,
},
mDataLoaded: false,
mLatest: false,
mPreparedEdit: false,
}
>>> $parserOutput = $page->getParserOutput( ParserOptions::newFromAnon() ) # parsercache is consulted here, empty HTML is returned
=> ParserOutput {#510}
>>> $parserOutput->getText()
=> "<div class="mw-parser-output"></div>"
>>>
>>> $parserOutputNoCache = $page->getParserOutput( ParserOptions::newFromAnon(), null, true )
=> ParserOutput {#5791}
>>> $parserOutputNoCache->getText()
=> "<div class="mw-parser-output"><div lang="en" dir="ltr" class="mw-content-ltr"></div><div id="mw-massmessage-addpages"><h2>Add pages</h2><form id="mw-massmessage-addform"><label for="mw-massmessage-addtitle">Title:</label><input id="mw-massmessage-addtitle" name="title"/><label for="mw-massmessage-addsite">Site:</label><input id="mw-massmessage-addsite" placeholder="meta.wikimedia.org" name="site"/><input id="mw-massmessage-addsubmit" type="submit" value="Add page" name="submit"/></form><div id="mw-massmessage-addedlist"><p>Pages added:</p><ul></ul></div></div><h2>Pages in this list</h2><ul><li><span class="mw-massmessage-targetlink"><a href="/wiki/User_talk:Martin_Urbanec_(test)" class="mw-redirect" title="User talk:Martin Urbanec (test)">User talk:Martin Urbanec (test)</a></span><span class="mw-massmessage-removelink">(<a data-title="User talk:Martin Urbanec (test)" data-site="local" href="#">remove</a>)</span></li></ul></div>"
>>>Once parser cache was left out of the game, correct HTML was returned.
I have very limited knowledge about parsing, so I don't know why $cpoParams->getGenerateHtml() returns false, but it seems to be a plausible explanation of what's happening here to me.
Tagging both MassMessage and MediaWiki-Parser, as fixing this task is likely going to require advanced knowledge about how parsing works in MW, rather than MM itself works (as demonstrated by the "do not use cache" flag above, MM's own code works as expected).