?safemode=1 intentionally blocks JavaScript when it loads content from the wiki
Closed, InvalidPublicBUG REPORT
Actions

Assigned To

None

Authored By

	Novem_Linguae
	Mar 26 2024, 5:06 PM

Description

Steps to replicate the issue (include links if applicable):

install mw:Extension:PageTriage
log out
as an IP, create page Test
log in as admin
visit page Test. Page Curation toolbar will be visible

now visit page Test with ?safemode=1

What happens?:

page curation toolbar not visible

What should have happened instead?:

page curation toolbar visible

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

if this is expected behavior, would suggest better documenting it. based on what I've read at https://www.mediawiki.org/wiki/Help:Locating_broken_scripts#Test_if_you_have_problems_related_to_user_scripts_or_gadgets and https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/Output/OutputPage.php#1779, I would have expected this PageTriage toolbar (javascript generated by an installed extension) to be visible even with safemode on, since it is not "scripts which can be modified by wiki users to load on this page"

Event Timeline

Novem_Linguae created this task.Mar 26 2024, 5:06 PM

Restricted Application added a project: MediaWiki-Platform-Team. · View Herald TranscriptMar 26 2024, 5:06 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

My hypothesis here is that the options module ext.pageTriage.externalTagsOptions for PageTriage is being considered a user-generated javascript bundle somehow. The class that loads the options, PageTriageExternalTagsOptions extends from the WikiModule class which is also appears to be used to load userjs and sitecss. I wonder if it might be setting some kind of variable flagging the module as a user-generated module.

If my hypothesis is correct, and ext.pageTriage.externalTagsOptions is being flagged as a user-generated module, then both it and everything that depends on it (including the rest of the toolbar UI) wouldn't load as well leading to the situation we are seeing here.

The Page Curation toolbar does load settings from https://en.wikipedia.org/wiki/MediaWiki:PageTriageExternalTagsOptions.js and https://en.wikipedia.org/wiki/MediaWiki:PageTriageExternalDeletionTagsOptions.js. Although we've kind of deprecated those and may eventually stop loading those completely.

In T361036#9663098, @Soda wrote:

My hypothesis here is that the options module ext.pageTriage.externalTagsOptions for PageTriage is being considered a user-generated javascript bundle

That's correct. As the module relies on on-wiki JS pages, it can't be considered safe. Any RL\Module with $origin set higher than 2 (ORIGIN_USER_SITEWIDE or ORIGIN_USER_INDIVIDUAL) is scrubbed out in safemode.

larissagaulia removed projects: MediaWiki-ResourceLoader, MediaWiki-Platform-Team.Apr 8 2024, 3:16 PM

I've re-titled. My understanding is that this is operating as designed, and so this task is a WONTFIX?

Indeed, you're all correct, this is the expected behavior. And @Soda's explanation of the specific way it happens is right too.

If you want PageTriage to be loaded in safemode, then you can remove the dependency on 'ext.pageTriage.externalTagsOptions', load it manually from your code with mw.loader.using, and handle the failure somehow (which will occur in safe mode, but also e.g. if the on-wiki JS code has a syntax error). For example, VisualEditor does that here. I don't know whether that would make sense with PageTriage though (is it even safe to load the code if the on-wiki configuration can't be loaded?). And I suppose if it's already kind of deprecated, then it might not be worth the effort anyway.

?safemode=1 intentionally blocks JavaScript when it loads content from the wikiClosed, InvalidPublicBUG REPORTActions

Description

Event Timeline

?safemode=1 intentionally blocks JavaScript when it loads content from the wiki
Closed, InvalidPublicBUG REPORT
Actions