Last modified: 2011-08-14 00:52:37 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 T31311, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29311 - [OutputPage] Create a method to remove items from mModules
[OutputPage] Create a method to remove items from mModules
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.20.x
All All
: Normal normal (vote)
: ---
Assigned To: John Du Hart
: easy, patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-07 22:34 UTC by Krinkle
Modified: 2011-08-14 00:52 UTC (History)
5 users (show)

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


Attachments
Proposed fix (709 bytes, patch)
2011-07-29 01:51 UTC, John Du Hart
Details

Description Krinkle 2011-06-07 22:34:07 UTC
As mentioned in bug 23985 comment 3 and on http://www.mediawiki.org/wiki/Thread:Manual_talk:JavaScript_unit_testing/QUnit_/_TestSwarm_environment,_Version_2, we should implement a way for extensions (and core maybe as well) to easily undo an addition.

Either by specific name (public function removeModules), and/or for all (public function resetModules/clearModules).
Comment 1 Brion Vibber 2011-06-07 22:56:49 UTC
Added a note on bug 23985 comment 4 that this might be better implemented there with aliases or overrides.

I'm not sure how much other use there might be for a removeModule but I'd tend to be leery of it. A module could still be pulled in by a dependency on something else, for instance.
Comment 2 Roan Kattouw 2011-06-08 11:27:29 UTC
(In reply to comment #1)
> I'm not sure how much other use there might be for a removeModule but I'd tend
> to be leery of it. A module could still be pulled in by a dependency on
> something else, for instance.
AFAIK Krinkle wants this for the QUnit special page, which needs to nuke all of mModules and only load test suites.
Comment 3 Brion Vibber 2011-06-08 18:21:52 UTC
That should just need a reset then; or keeping it from having filled out with stuff in the first place.

It's probably wise to be able to run a lot of tests in-place in a real environment though; if modules conflict for instance, that's information tests should be turning up.

Only the lowest-level tests of the loader itself probably really require running in a clean slate environment.
Comment 4 John Du Hart 2011-07-29 01:51:02 UTC
Created attachment 8834 [details]
Proposed fix

Created a patch with both the removeModules and resetModules functions as requested originally. Feel free to leave out the removeModules function if you feel it's unsafe.
Comment 5 Roan Kattouw 2011-08-02 12:19:58 UTC
(In reply to comment #4)
> Created attachment 8834 [details]
> Proposed fix
> 
> Created a patch with both the removeModules and resetModules functions as
> requested originally. Feel free to leave out the removeModules function if you
> feel it's unsafe.
Looks good to me. I'd appreciate it if another committer could apply this, I don't have a clean working copy right now.
Comment 6 Mark A. Hershberger 2011-08-02 14:29:37 UTC
(In reply to comment #5)
> Looks good to me. I'd appreciate it if another committer could apply this, I
> don't have a clean working copy right now.

r93751
Comment 7 Dan Collins 2011-08-04 22:05:54 UTC
Apparently fixed in r93751
Comment 8 Krinkle 2011-08-05 06:59:34 UTC
The original use case was to be able to surpress/filter out some modules form loading on a SpecialPage that needs isolation.

However it appears MediaWiki recently got support for that already by implementing "origin restrictions" (eg. when set to "CORE" resources by users, sites and extensions will not be loaded).

This removes the original use case from this feature request.

When looking back at what this method leaves, I'm not sure we should keep it. It can make debugging hard and also sets wrong expectation (ie. if a method adds a module to the output, it should actually get outputted and not unloaded by something else).
Comment 9 Mark A. Hershberger 2011-08-05 12:46:13 UTC
I defer to your judgement, Krinkle.  Please feel free to revert.
Comment 10 John Du Hart 2011-08-14 00:52:37 UTC
Closing as WONTFIX.

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


Navigation
Links