Change 131766 had a related patch set uploaded by Gerrit Patch Uploader:
Load required modules from messages in parseText()

https://gerrit.wikimedia.org/r/131766

Change 196626 had a related patch set uploaded (by Umherirrender):
Add metadata from ParserOutput on message parse to OutputPage

https://gerrit.wikimedia.org/r/196626

Change 196626 abandoned by Umherirrender:
Add metadata from ParserOutput on message parse to OutputPage

Reason:
May have to many side effects or break changes

https://gerrit.wikimedia.org/r/196626

I liked https://gerrit.wikimedia.org/r/196626, can we revive it? We could try limiting this feature to a few message which run into this problem often ('edittools' in particular), if we're concerned about too many random things breaking. (cc @Umherirrender)

T113340 is also a request for automatic loading modules. Maybe this can combined or build on each other.

In T66969#1767579, @matmarex wrote:

I liked https://gerrit.wikimedia.org/r/196626, can we revive it? We could try limiting this feature to a few message which run into this problem often ('edittools' in particular), if we're concerned about too many random things breaking. (cc @Umherirrender)

Feel free to upload under your own name, if you have a concept in your head. There is no need for attribution to my user name.

Whitelisting messages by adding another call avoids b/c problems, but maybe makes things not easier.

This is a side-effect of the (intentional) ommitting of "parser output meta data" when displaying text from a page in parts of the interface on a different page. This applies to the edit notice here, for example.

The reason for this is to prevent confusing or broken functionality, especially when it comes to language links and categories. Enabling these here would effectively change the edit form to a preview submission. As it stands, these language links and categories have no where to go. Adding them to the "real" page being rendering seems possibly confusing or wrong since the user probably expects the menu for "Hidden categories" at the bottom of their editing screen to relate to the page they are editing, not the editnotice page being transcluded temporarily as part of the edit notice. Plus the added surprise of these also showing up when actively previewing your edit (where the editnotice remains visible as well, and so the same would happen). This would make the preview difficult to understand when some of the categories shown at the bottom of the preview are not actually going to be there when you save the page.

I suppose one thing we could do is invent a new form of meta data where we ignore everything except the added stylesheets and modules. This has the upside of more or less doing the right thing for most cases, most of the time. With the downside of being a potentially confusing technical measure that may have unexpected consequences. This is part of why the previous approach was abandoned during code review.

I think offering an internal method that omits most meta data, but preserves styles, might make a good compromise. Specifically, it would continue to ignore categories, language links, as well as JS modules and JS config vars. I'm thinking mainly of things like WikiHiero and Babel showing correctly in an Editnotice (ref T53038: Extension styles not loaded when used in edit notice).

What we have today:

• OutputPage::addWikiTextAsContent: This adds the full ParserOutput html + all metadata.
  • Usage: Permission errors (incl templates). Copyright warning (incl interface message wikitext parsed in-place).
• OutputPage::addParserOutputContent: This adds HTML + styles and JS modules.
  • Usage: Special:ExpandTemplates, pagers such as Special:ListFiles and Special:AllMessages.
• OutputPage::addHtml + msg->parseAsBlock(): This adds HTML only.
  • Usage: This is what most interface messages use. It is parsed in a separate parsing context and only the text or HTML is preserved. This is usually the best option for small and widely rendered messages. But, is also used by Editnotices currently, and perhaps shouldn't be.