According to a German Wikisource thread, the bug is present since 10/14 days, which matches the rollout of c1f80efe05349cc39cb82dc9347b0a7699b11dfd (T304303) on 18 May (11 days ago). Looking at the code, ProofreadPage\Page\PageContentHandler::unserializeContentInWikitext (rEPRP includes/Page/PageContentHandler.php:225-289 (at 0bed1ccf)) depends on the presence of the <noinclude> tags, and exactly those were removed in that patch. I don’t think we can come up with a solution that doesn’t include a bunch of hacks to patch the 2010 and 2006 wikitext editors (unless the live preview is substantially rewritten to natively support editing multiple slots at once), so maybe the easiest solution is to just revert the changes to ext.proofreadpage.page.edit.js.

Indeed, this bug is related to c1f80efe05349cc39cb82dc9347b0a7699b11dfd (T304303): the live preview feature relies on the JS API allowing to fetch the current content of the editing area. To fix T183950 we dropped the hack inside of ProofreadPage that provides not only the page body but also the proofreading level and the page header/footer as page content. So, after this change, only the page body is fed to the live preview feature, hence the bug. A possible solution might be to add back the "complete page content" hack inside of ProofreadPage but some signficant work would be required to make features like find/replace work with this hack.

This bug affects not just the proofread status, which is more cosmetic than anything, but also all other uses of the header and footer, which is a lot more troublesome. Most obviously it means you can't preview any changes to the content in the header/footer (a running header, for example); but it also breaks the use of any page-spanning templates. For example, on enWS Template:TOCstyle generates a table and relies on having {{TOCstyle|header=yes}} in the header so that when invoked in the body with {{TOCstyle|continues=yes}} it can output only a markup fragment. Since the preview doesn't have the header the body ends up being parsed as generic unordered list markup. enWS has a number of templates that operate on this model. And without testing I imagine it also will affect any other page-spanning constructs such as basic table wikimarkup (multipage tables are common in all sorts of works).

That's a pretty major annoyance with significant impact on workflow, and it makes an already complicated solution effectively unmanageable for less experienced or less technically-inclined users. Given search and replace has been broken for half a decade, I'm not sure this is a reasonable tradeoff.

Absent further comments let me be a bit more direct: looking at T304303 I see no upside that to me justifies breaking this long-standing and core end-user-visible functionality. Page-spanning constructs (e.g. tables, like the tables of contents in just about every book) are now literally impossible to work with when live previews are on, and it is in practice impossible for a user (even experienced users) to tell what's going on or how to work around it. IMO, if this cannot be fixed some other way relatively soon the triggering change will have to be rolled back.

In T309451#8074277, @Xover wrote:

Absent further comments let me be a bit more direct: looking at T304303 I see no upside that to me justifies breaking this long-standing and core end-user-visible functionality.

Live preview is a fairly new feature that is built with the default wikieditor interface in mind. The normal preview feature (without the 'live' aspect) should work properly.

(The 'live preview' feature can be disabled by unchecking the checkbox at Preferences > Editing > Preview > Show previews without reloading the page)

In T309451#8074743, @Soda wrote:

Live preview is a fairly new feature

It depends how you define ‘fairly new’. Yes, it’s much newer than the internet, even a bit newer than MediaWiki itself, but I wouldn’t call a 17-year-old (c05eeb66755 / rSVN6709 – the 6709th commit in the history of MediaWiki!) feature ‘fairly new’.

In T309451#8074784, @Tacsipacsi wrote:

In T309451#8074743, @Soda wrote:

Live preview is a fairly new feature

It depends how you define ‘fairly new’. Yes, it’s much newer than the internet, even a bit newer than MediaWiki itself, but I wouldn’t call a 17-year-old (c05eeb66755 / rSVN6709 – the 6709th commit in the history of MediaWiki!) feature ‘fairly new’.

Ah wait I was wrong, I confused this with the fairly recently implemented 'realtime preview' feature, have struck the previous comments :(

I wouldn't consider this feature a live preview as you have to click a button. It requires an action so not live. I think that is why Soda confused this bug report with "Realtime preview" (which reloads itself and hence is actually a live preview)... But I won't quibble about it ;-)

It’s not about what you consider this feature to be, it’s about how it’s called; it has a name, which happens to be “live preview”. Granted, it’s much less “live” than the “real-time preview”, but this is how it was named eighteen years ago. (At that time, both computers and internet connections were much slower, so auto-refresh may not have even been possible for many.)

Ping?

It's currently impossible to work with page-spanning tables (they show up as gobbledygook due to missing open table wikimarkup), previewing changes to the header (e.g. a running header), any formatting that requires a template or similar in the header, etc. I'm getting tired of having to round-trip into Preferences to toggle this off and on again every single time I have work with such constructs.