This is essentially about triggering OutputPage::disallowUserJs() on an arbitrary page - which restricts loaded modules to just those with an origin that is core (see ResourceLoaderModule constants) - and filtering out modules with origin of "user-sitewide" or "user-individual".

Which makes the page restricted in a way similar to Special:Preferences and Special:UserLogin.

Change 345471 had a related patch set uploaded (by Catrope):
[mediawiki/core@master] Add ?safemode=1 to disable user JS/CSS

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

Change 345471 merged by jenkins-bot:
[mediawiki/core@master] Add ?safemode=1 to disable user JS/CSS

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

Noting here in case someone else was curious: The Tech News used the example https://en.wikipedia.org/wiki/Literature?safemode=1 but if you scroll to the bottom you'll see the navboxes are all broken. This apparently is because the styling is defined in common.css, which is also disabled in safe mode. It makes sense for safe mode to work in this way... but it might be useful to have a way to include the common JS/CSS, and perhaps even default-enabled gadgets (so similar to what a newly registered account would see).

Taking this a step further, it would be really awesome to disable everything except some specific gadget. There are the Load JS and CSS by URL snippets, but alas we need Common.js to be loaded in order for that to work :(

So say someone is having trouble with a gadget I wrote (happens a lot :), ideally I could link them to https://en.wikipedia.org/wiki/Literature?safemode=1&withJS=MediaWiki:Common.js|MediaWiki:Gadget-foo.js, that way I would easily be able to find out if it was a conflicting gadget/script/etc. that is causing the issue. This basically boils down to a native solution for withCSS and withJS, so I've created T163150

How could we survive so far without this, I wonder.
(Also, any chance we can come up with something that also investigates Beta Features? Bonus points if it's magically able to tell us exactly where the problem is :D )

In T152169#3187809, @MusikAnimal wrote:

Noting here in case someone else was curious: The Tech News used the example https://en.wikipedia.org/wiki/Literature?safemode=1 but if you scroll to the bottom you'll see the navboxes are all broken. This apparently is because the styling is defined in common.css, which is also disabled in safe mode. It makes sense for safe mode to work in this way... but it might be useful to have a way to include the common JS/CSS, and perhaps even default-enabled gadgets (so similar to what a newly registered account would see).

I agree that it would be good to have a "pretend I'm an anon / new account" mode that includes site JS/CSS and default Gadgets, but not non-default Gadgets or user JS/CSS. That was actually my original intent with safe mode, I didn't realize that sitewide JS would be excluded too. Excluding it can be useful sometimes, but most of the time it's probably counterproductive.

This would be a bit trickier to pull off though, because excluding user JS/CSS would need to be done in core while excluding non-default Gadgets would need to be done by the Gadgets extension. Unless we change the Gadgets extension to set the origin to ORIGIN_USER_INDIVIDUAL for non-default Gadgets, or add an origin level for non-default Gadgets in between ORIGIN_USER_SITEWIDE and ORIGIN_USER_INDIVIDUAL.

I think a new origin might be the most elegant solution: keep default Gadgets at untrustworthiness level 3 (ORIGIN_USER_SITEWIDE), put non-default Gadgets in a new ORIGIN_USER_PREFERENCE with untrustworthiness level 4, and renumber ORIGIN_USER_INDIVIDUAL to level 5.

@Krinkle , what are your thoughts on this?

@Catrope Not sure. Imho safemode is already for a fairly narrow edge case to have built-in, but it's a primitive that we can build on, which is why I liked it.

Similarly I think T29766 would also make a good primitive. That means you can do ?safemode=1&withModule=site or ?safemode=1&withModule=site&withModule=ext.gadget.foo. That should satisfy the use case presented here.

While more verbose, this is a powerful building block that is both more flexible and easier to maintain. It also avoids trying to bring more differentiation to MediaWiki core with regards to different kinds of trust and user/site scripts, which I believe is already quite complicated. Adding this additional concept will likely introduce certain expectations about other places where it would work ("for consistency") that I don't think we actually want and that likely won't have good use cases.

Confusingly, EditPage also has a &safemode= parameter which is entirely unrelated (luckily it should be going away soon).