Changing product/component to MediaWiki extensions/Gadgets since that's the Gadgets that should check $out->isUserJsAllowed() in wfGadgetsBeforePageDisplay().

$out->isUserJsAllowed() always returns false for the cirtical pages, which is good. But it also returns false if $wgAllowUserJs is false, which is bad. it would mean that Gadgets don't work on wikis with user JS disabled.

Gadgets are more like site JS, not so much like user JS. So, $out->isUserJsAllowed() does not seem to be the right function to call.

The only alternative I see is to add more hard-coded checks in the gadgets extension. Which also sucks. Ideas?

fixed in r64670 by adding hard-coded checks for Special:Userlogin and Special:Resetpass. Leaving a nicer solution for later.

M8R-cyc3n3 wrote:

Gadgets are more like site JS, not so much like user JS. So,
$out->isUserJsAllowed() does not seem to be the right function to call.

I guess you could add something like $out->isWikiJsAllowed()
which is basically:

/* do we load js from a wiki page under any circumstance */
return $wgAllowWikiJs && !($title->isCriticalPage());

And $out->isUserJsAllowed() would then become:

return $wgAllowUserJs && $out->isWikiJsAllowed();

In any case I was had hoped r64670 would be a candidate
for expedited scapping.

M8R-cyc3n3 wrote:

i don't know how new it is, but it just occurred to me that [[Special:Changepassword]] is now a separate page (!) so
we'll want to disable gadgets there too.

Should we perhaps not have custom js/css on any special pages then white-list
the ones it should be available?

M8R-cyc3n3 wrote:

Should we perhaps not have custom js/css on any special
pages then white-list the ones it should be available?

that seems a little rash as most of the js i've written and
used has been to enhance the functionality of special pages.

pages which leave the server while already containing any
element like <input name="wpPassword"> should refrain from
loading on-wiki javascript. seems like a no-brainer.

yeah, no solution is perfect, and a password prompt could be
added in post-production to potentially any page byOnloadHook
orCrook but i'd more likely suspect something is amiss than
remit my password for no apparent reason.

overlordq wrote:

I would agree with p858snake, that white listing instead of blacklisting would be a better solution.

happy.melon.wiki wrote:

Nicer implementation dones in r81524.