Page MenuHomePhabricator

Disable Gadget wherever user css/js is disabled, or at least aim for consistency
Closed, DeclinedPublic

Description

I use some some Gadgets but now I discovered that they don't work on Special:Preferences for what ever reeason. Very confusing for the user is the css gadget he uses changes the layout heavily and he suddenly uses the normal layout on Special:Preferences.

Can anyone confirm?


Version: unspecified
Severity: normal

Details

Reference
bz18186

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:32 PM
bzimport set Reference to bz18186.
bzimport added a subscriber: Unknown Object (MLST).

"some some Gadgets" = some CSS Gadgets

Ok you can test it on WP. Select the last interface setting "Use a black background with green text on the Monobook skin", save, browse away, purge cache, go back to prefs.

Tested in monobook and modern skin on MW 1.14.

Intended behavior for case the gadget is written incorrectly and/or causes malfunction, so it could be turned off.

Ok. Very confusing nontheless :)

herd wrote:

Well, lets make use of this bug then, rather than let it simmer.

User CSS/JS is disabled in: [[Special:ChangePassword]] [[Special:UserLogin]] [[Special:Preferences]]

Gadgets disabled in: [[Special:Preferences]]

It was probably intended to protect users from malicious scripts and/or corruption of the preferences form, but it seems like anywhere a password is entered they should be disabled too, like user CSS/JS is.

I can understand it for User CSS/JS but bad Gadgets? I mean only sysops can add / change them though.
Well, I woulod disable this if I knew how to since I'm the only sysop and I test / trust my enabled Gadgets :)

Well...

I also trusted in this piece of code that I've added at Commons:
https://commons.wikimedia.org/w/index.php?diff=20330266
But... because of a table created by other user without the closing |}:
https://commons.wikimedia.org/w/index.php?diff=12702103
the CSS I've used was also hidding the Save button.

So, I've "blocked" myself from editing because of that CSS code... (and I could not revert my edit, I could not ask for help logged in... =/)

Then, when I realized that the preferences are not afected by css/js, I was able to change my language settings to a language other than pt-br, to wich [[commons:MediaWiki:Copyrightwarning/pt-br]] is not loaded, and then revert my own edit (after 10 days):
https://commons.wikimedia.org/wiki/User:He7d3r/monobook.css?diff=next&oldid=20344419

Considering this (fun) situation, and the fact that "when we look for bugs we can only be sure of the presence of them, not of the absence", I think it is good to have the Special:Preferences page not affected by our codes...

Now that ResourceLoader is available, perhaps it could include a flag to allow certain gadgets to run anyway on special pages.

On second thought, this is intended behaviour for security reasons, so my suggestion would defeat that purpose. Therefor close as WONTFIX.

(In reply to comment #8)

On second thought, this is intended behaviour for security reasons, so my
suggestion would defeat that purpose. Therefor close as WONTFIX.

Why is gadgets ENABLED on [[Special:ChangePassword]] [[Special:UserLogin]]
[[Special:Preferences]] (see comment #4) if the aim is to have more security? Why can't we have consistency between gadgets and user scripts?

Because gadgets can only be installed by administrators, so there is less risk then with user scripts. But as even admins *can* make mistakes, gadgets need to be disabled in Preferences so the damage can be undone.

I think he ment that user scripts are disabled on mentioned special pages but gadgets not.

I know what he ment. User scripts are disabled on any password-related page to prevent malicious scripts from compromising the account.

alexsm333 wrote:

I don't see why Common.js was disabled in Preferences. Password is not typed on that page. Email address is still not protected ("readable" with a script from other pages).

Can we have a separate "preferences-only" .js page that would be easier to track across projects? I used to have http://ru.wikipedia.org/wiki/MediaWiki:Preferences.js to do some useful stuff in preferences...

(In reply to comment #15)

Can we have a separate "preferences-only" .js page that would be easier to
track across projects? I used to have
http://ru.wikipedia.org/wiki/MediaWiki:Preferences.js to do some useful stuff
in preferences...

Use cases please, examples.