OK, so, first thing first: we need to fix the bug you've uncovered so it doesn't corrupt the page like this.

However, the edit you're trying to do (not the bug you're uncovering) is not possible right now with VisualEditor, and almost certainly never will be. In the mean time, you can make these edits in the wikitext editor. Here are some reasons:

• VisualEditor is a visual editor
  
  Writing raw wikitext or HTML will not work. Manually writing <div style="color:blue;"> will never do anything you want, unless you're writing a help page about how to write wikitext somewhere else. To do this, you'd want a specialised tool based off T72498: VisualEditor: Be able to make block-level edits (e.g. language of a <div> / <ol> not a <span>) and thence T72484: VisualEditor: Be able to make block-level items centred (and other styles).

• We intentionally don't let you make unbalanced edits
  
  You're trying to write <header><div style="color:blue;"></header><page>…</page><footer></div></footer>. This is fundamentally not compatible with a visual editor. It's also something that eventually won't work in MediaWiki in general (see below), so we need to find a better way to do this task.

• Inline styles are very bad (and will eventually not work in MediaWiki at all)
  
  There are various security, scalability and accessibility tasks related to this. The overall "let's fix it" task is T28508: Content Security Policy (CSP). You'd be able to do this more neatly with T483: RfC: Allow styling in templates which will come sooner, though (a) that still won't let you edit it nicely in VisualEditor – you'd have to know to add a template – and (b) that will be impossible once T114445: [RFC] Balanced templates is implemented.

• This is a wikitext hack awaiting feature support
  
  What you actually want is not to hack around with <div>s that magically are in <noinclude>s, but for ProofreadPage to understand that the page's contents have a bespoke background colour (and for there to be rules about how said colours should be used).

Once we've fixed this bug, we can start looking at giving the proper functionality for this need.

In T138604#2405228, @Jdforrester-WMF wrote:

OK, so, first thing first: we need to fix the bug you've uncovered so it doesn't corrupt the page like this.

• We intentionally don't let you make unbalanced edits
  
  You're trying to write <header><div style="color:blue;"></header><page>…</page><footer></div></footer>. This is fundamentally not compatible with a visual editor. It's also something that eventually won't work in MediaWiki in general (see below), so we need to find a better way to do this task.

@Jdforrester-WMF:
such a way of editing in Page: namespace stems from the specificity of Wikisource. On Page: namespace each page of text is a "separate page", but after their transclude to Main namespace the work has become one.

Because sometimes on the pages of a book, there is a separate (divided into two pages) the other/different style/... of a block of text, after transcluding to Main namespace these two distinct parts (the end of previous and beginning of the next page) must be combined into one block.

Until now, it was implemented in such a way
...<page>… <tag> different style part 1 </page><footer></tag></footer> and on the next page <header><tag></header><page>different style part 2</tag>…</page>...
or
<page>… <tag> different style part 1 <noinclude></tag></noinclude></page> and on the next page <page><noinclude><tag></noinclude> different style part 2 </tag>…</page>
see: previous page, next page and after transclusion

see: thousands of pages on fr ws
thousands of pages on en ws

so... If I do not know the other way to do that...
conclusion: ve is fundamentally not compatible with a Page NS?

Z.

In T138604#2405621, @Zdzislaw wrote:

so... If I do not know the other way to do that...

The other way does not exist yet. We'll make it work later.

After more investigation this issue seems to only happens when the Parsoid cache still has a content with the <div class="page-text">

In T138604#2406393, @Tpt wrote:

After more investigation this issue seems to only happens when the Parsoid cache still has a content with the <div class="page-text">

Does that mean this is now Resolved as all the old pages have expired?

Does that mean this is now Resolved as all the old pages have expired?

Sadly no as the <div class="pagetext"> is still in the Wikitext of the last revision. Solving this issue would require to add a new revision to all affected pages or making sure that they goes throw a unserialization/serialization by the ContentHandler.

I can't reproduce this exactly now. When I tried, the <div …> and </div> tags I typed got nowikied, as I would expect. It should not be possible to actually insert a real div node spanning from the header to the footer in VE interface.

The searches you linked in the first comment seem dead – the pl.ws one returns 0 results, and the other two return mostly pages containing a duplicated <div class="pagetext"><div class="pagetext"> tag, which seems like a separate kind of a problem altogether.

I think this originally happened because of a combination of three problems:

• Some unspecified Parsoid issue that prevented the tags from being nowikied (apparently fixed)
• T155362, where ProofreadPage magically removes </div> tags in noinclude
• T196863, where using VE to edit pages with complicated headers/footers corrupts the wikitext

Unless you find a way to reproduce this, I think we should close this task and instead work on the two I linked.