Last modified: 2013-06-18 15:56:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20186, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18186 - Disable Gadget wherever user css/js is disabled, or at least aim for consistency
Disable Gadget wherever user css/js is disabled, or at least aim for consistency
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
Gadgets (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-26 22:02 UTC by Subfader
Modified: 2013-06-18 15:56 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Subfader 2009-03-26 22:02:14 UTC
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?
Comment 1 Subfader 2009-03-26 22:06:38 UTC
"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.
Comment 2 Danny B. 2009-03-26 22:38:31 UTC
Intended behavior for case the gadget is written incorrectly and/or causes malfunction, so it could be turned off.
Comment 3 Subfader 2009-03-27 10:30:25 UTC
Ok. Very confusing nontheless :)
Comment 4 Splarka 2009-03-27 10:56:04 UTC
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.
Comment 5 Subfader 2009-03-27 17:56:21 UTC
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 :)
Comment 6 Helder 2009-08-14 19:29:40 UTC
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
Comment 7 Erwin Dokter 2011-10-17 08:46:32 UTC
Now that ResourceLoader is available, perhaps it could include a flag to allow certain gadgets to run anyway on special pages.
Comment 8 Erwin Dokter 2011-12-15 14:00:35 UTC
On second thought, this is intended behaviour for security reasons, so my suggestion would defeat that purpose. Therefor close as WONTFIX.
Comment 9 Helder 2011-12-15 14:18:05 UTC
(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?
Comment 10 Erwin Dokter 2011-12-15 14:27:12 UTC
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.
Comment 11 Subfader 2011-12-15 15:16:05 UTC
I think he ment that user scripts are disabled on mentioned special pages but gadgets not.
Comment 12 Erwin Dokter 2011-12-15 15:26:16 UTC
I know what he ment. User scripts are disabled on any password-related page to prevent malicious scripts from compromising the account.
Comment 15 AlexSm 2011-12-28 06:33:49 UTC
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...
Comment 16 Krinkle 2012-01-02 16:06:45 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links