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

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz18186.
Subfader created this task.Via LegacyMar 26 2009, 10:02 PM
Subfader added a comment.Via ConduitMar 26 2009, 10:06 PM

"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.

bzimport added a comment.Via ConduitMar 26 2009, 10:38 PM

danny.b wrote:

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

Subfader added a comment.Via ConduitMar 27 2009, 10:30 AM

Ok. Very confusing nontheless :)

bzimport added a comment.Via ConduitMar 27 2009, 10:56 AM

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.

Subfader added a comment.Via ConduitMar 27 2009, 5:56 PM

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 :)

He7d3r added a comment.Via ConduitAug 14 2009, 7:29 PM

Well...

I also trusted in this piece of code that I've added at Commons:
http://commons.wikimedia.org/w/index.php?title=User:Heldergeovane/monobook.css&diff=prev&oldid=20330266
But... because of a table created by other user without the closing |}:
http://commons.wikimedia.org/w/index.php?title=MediaWiki%3ACopyrightwarning%2Fpt-br&diff=12702103&oldid=3593718
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):
http://commons.wikimedia.org/w/index.php?title=User:Heldergeovane/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 afected by our codes...

Helder

Edokter added a comment.Via ConduitOct 17 2011, 8:46 AM

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

Edokter added a comment.Via ConduitDec 15 2011, 2:00 PM

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

He7d3r added a comment.Via ConduitDec 15 2011, 2:18 PM

(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?

Edokter added a comment.Via ConduitDec 15 2011, 2:27 PM

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.

Subfader added a comment.Via ConduitDec 15 2011, 3:16 PM

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

Edokter added a comment.Via ConduitDec 15 2011, 3:26 PM

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

He7d3r added a comment.Via ConduitDec 17 2011, 1:43 PM

Per:
https://commons.wikimedia.org/w/index.php?title=User_talk:Krinkle&oldid=63565380#MediaWiki:Gadgets-definition
[[MediaWiki:Common.js]] is not loaded on [[Special:Preferences]] anymore.

bzimport added a comment.Via ConduitDec 28 2011, 6:33 AM

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

Krinkle added a comment.Via ConduitJan 2 2012, 4:06 PM

(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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.