URL parameter to temporarily disable user scripts/gadgets
Closed, ResolvedPublic

Tokens
"Like" token, awarded by MGChecker."Doubloon" token, awarded by RandomDSdevel."Love" token, awarded by He7d3r."Love" token, awarded by MusikAnimal."Like" token, awarded by IKhitron."Like" token, awarded by Elitre."Love" token, awarded by Trizek-WMF.
Assigned To
Authored By
Mattflaschen-WMF, Dec 2 2016

Description

The idea is like Firefox Safe Mode, so you can temporarily disable all gadgets and user scripts (and probably styles too) to see if a bug is reproducible without them.

There is no other way to do this, except:

  • Individually unchecking all the gadgets (while noting which you had checked) (you can also reset all preferences, but that's not acceptable except for very new users).
  • Manually modifying all the user script pages (common.js, vector.js, global.js, etc.)
  • Making sure you hard refresh/clear your cache

then undoing all that.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 2 2016, 2:31 AM

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.

Krinkle triaged this task as Low priority.Feb 9 2017, 10:22 PM
Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.

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

Krinkle assigned this task to Catrope.Mar 29 2017, 9:05 PM
Krinkle moved this task from Backlog to Accepted: Enhancement on the MediaWiki-ResourceLoader board.

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

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

Jdforrester-WMF closed this task as Resolved.Apr 10 2017, 7:09 PM
Jdforrester-WMF edited projects, added User-notice; removed Patch-For-Review.

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

Elitre added a subscriber: Elitre.Apr 21 2017, 10:59 AM

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 )

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?

MGChecker added a subscriber: MGChecker.

@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 I 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.