Just for clarity, this will catch any unhandled fostered parenting issues in Parsoid. VE-DOM-dirtying will not be caught by this.

(In reply to comment #1)

Just for clarity, this will catch any unhandled fostered parenting issues in
Parsoid.

Depending on how it's written, it could catch these (or have a mode to detect these), by serializing the DOM out to a string and parsing it back in again.

With or without this kind of DOM normalization though, mass-testing articles to find selser bugs would be very awesome.

VE-DOM-dirtying will not be caught by this.

Fortunately, VE does its own detection for this at run time: https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=visualeditor-needcheck

(In reply to comment #2)

(In reply to comment #1)

Just for clarity, this will catch any unhandled fostered parenting issues in
Parsoid.

Depending on how it's written, it could catch these (or have a mode to detect
these), by serializing the DOM out to a string and parsing it back in again.

Yes, that is the intention.

With or without this kind of DOM normalization though, mass-testing articles
to find selser bugs would be very awesome.

We haven't yet figured out how to do this reliably. We still have same problem that I mentioned on the VE/F page about absence of an oracle to tell us authoritative wikitext to compare against. So, the best we can do is simulate null edits, or modify text, etc. But those are, for the most part, the uninteresting bits of selser testing -- the most interesting bugs show up with more complex edits, and that is the bit that needs to be solved for using it in an automated manner in rt-testing.

Change 85990 had a related patch set uploaded by Marcoil:
Bug 54339: Add _rtselser endpoint in web API

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

Change 85990 merged by jenkins-bot:
Bug 54339: Add _rtselser endpoint in web API

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