First off, a brief disclaimer: post-1.39 versions of MW are untested and, in this sense, "unsupported"; but of course 1.39 will go EOL at some point, and then social tools will target the next LTS (more details on MW.org @ mw:Social tools/MediaWiki compatibility). So in a way, you're charting uncharted waters here - thank you for your bravery, it's appreciated! :)

Other than the bug manifesting itself on QuizGame's main special page, I'm not seeing anything else that'd indicate that this is strictly speaking a bug in QuizGame. Rather, looking at the backtrace, it looks like it's a VisualEditor one instead. VE's hooks class' onSkinTemplateNavigation__Universal has this line:

$isRemote = !$wikiPageFactory->newFromTitle( $title )->isLocal();

This, somewhat incorrectly, seems to assume that the WikiPageFactory#newFromTitle will always return something that represents "a proper page" (however "proper" may be defined there...). Now, to be fair to VE devs, they're hardly the only ones doing something like this; judging by a quick codesearch, almost all callers assume that WikiPageFactory#newFromTitle will not exception out. The only one that seems to bother implementing a try-catch loop is includes/installer/Installer.php. Weird.

As a VisualEditor developer, one could argue that it's very unusual to see content action tabs on a special page. I'm inclined to agree, but to also note that they actually make perfect sense in the context of QuizGame and related extensions, namely PictureGame and PollNY: two of these three (PollNY is the odd one out, sorta; it does use the new Poll: namespace for its new content, but that's somewhat incomplete and you should always be modifying PollNY data via the Special:*Poll pages like Special:UpdatePoll; basically PollNY currently suffers from the same stuff that FanBoxes did earlier this year, prior to a84d8f4025f203e5bd473dda9e133c79dce511ab) implement content that exists and is editable by some users (e.g. admins), but such content does not have any corresponding wiki page, they only exist in the underlying DB tables and thus the relevant special page(s) is the main UI for altering said data.

cc'ing @matmarex for input on this.

In T376487#10204465, @ashley wrote:

First off, a brief disclaimer: post-1.39 versions of MW are untested and, in this sense, "unsupported"; but of course 1.39 will go EOL at some point, and then social tools will target the next LTS (more details on MW.org @ mw:Social tools/MediaWiki compatibility). So in a way, you're charting uncharted waters here - thank you for your bravery, it's appreciated! :)

Thanks for the kind words! As far as my knowledge it will be released for public consumption in December this year, I'm looking forward to that and also looking to connect more with you regarding things like these.

I'm not seeing anything else indicating that this is strictly a bug in QuizGame. Rather, looking at the backtrace, it seems like it's a VisualEditor one instead.

The issues disappear from my view in the same local XAMPP test instance when I disable the VE + dependencies. So far, it's quite "normal" for me.

Judging by a quick codesearch, almost all callers assume that WikiPageFactory#newFromTitle will not exception out.

That reminds me of what happened to THERAC-25 in the 80s...

The VisualEditor code using isLocal() (note that there's one more call site) just wants to display some special messages for files automatically copied from Commons, global user pages automatically copied from Meta-Wiki, etc. If you can rewrite that code so that this functionality still works, while not crashing when combined with Social Tools, I'm sure that would be a welcome patch.