Last modified: 2014-09-15 12:46:19 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 T72824, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70824 - 2.0 Figure out how gadget naming collisions should work, and document it
2.0 Figure out how gadget naming collisions should work, and document it
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Gadgets (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: gadgets-2.0
  Show dependency treegraph
 
Reported: 2014-09-14 08:46 UTC by Kunal Mehta (Legoktm)
Modified: 2014-09-15 12:46 UTC (History)
6 users (show)

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


Attachments

Description Kunal Mehta (Legoktm) 2014-09-14 08:46:58 UTC
From https://www.mediawiki.org/wiki/ResourceLoader/V2_Task_management:

(RK) Figure out how gadget ID naming collisions should be handled, define this somewhere, and enforce it

---

I think local gadgets should take precedence, and then give precedence to whatever shared repo is first in $wgGadgetRepositories.
Comment 1 Kunal Mehta (Legoktm) 2014-09-15 12:46:19 UTC
Hmm, something else I thought of. Right now if a user enables a gadget "foo", and a repo higher up in the precedence chain creates a gadget named "foo" as well, the user will now get the JS/CSS from the new repo instead of what they actually enabled. If we make the local repo highest priority, a local gadget-manager could override popular global gadgets in this form to hypothetically compromise accounts. Or something not so good.

Possible solution: Embed the repo name in the preference key, so that if the source of a gadget changes, the user won't keep the same preference value. Might be a bit confusing from a UX perspective.

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


Navigation
Links