As the preferred way to access the wg* variables in JavaScript is to use mw.config.get()/.set(), accessing them as globals (i.e. as members of window) should show deprecation notices in debug mode, just like it is done for the functions from wikibits.js.
Description
Description
Details
Details
- Reference
- bz56550
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| mw.config: Show deprecation notices when accessing globals | mediawiki/core | master | +73 -9 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T52039 Proposed changes to default settings (DefaultSettings.php) (tracking) | |||
| Declined | Dereckson | T72366 Set $wgLegacyJavaScriptGlobals = false on ptwiki and ptwikibooks | |||
| Resolved | Ladsgroup | T72470 Remove legacy javascript globals | |||
| Resolved | Jdforrester-WMF | T35837 Set $wgLegacyJavaScriptGlobals = false by default | |||
| Resolved | Krinkle | T58550 Show deprecation notices when accessing wg* JavaScript globals | |||
| Resolved | None | T67011 Set $wgLegacyJavaScriptGlobals = false on test2wiki | |||
| Resolved | phuedx | T177259 Collection using deprecated global variables |
Event Timeline
Comment Actions
mw.config.get('wg*') is currently basically a wrapper for window.wg*. To make such deprecation notices possible we'd have to duplicate the values, which could cause them to get out-of-sync if something modified them after page load.
Comment Actions
(In reply to comment #1)
mw.config.get('wg*') is currently basically a wrapper for window.wg*. To make
such deprecation notices possible we'd have to duplicate the values, which
could cause them to get out-of-sync if something modified them after page
load.
Is this an actual issue? Once they are set, they shouldn't be changed anyway. So using a new object for mw.config.values instead of window and copying the variables over when they are set the first time using mw.log.deprecate shouldn't break more than replacing some of the wikibits.js functions with $.noop will break.
(In reply to comment #2)
Hm, how would deprecation actually work? Can we add getters on the window
object?
Yes, if you don't believe it, have a look at wikibits.js.
Comment Actions
(In reply to comment #3)
(In reply to comment #1)
mw.config.get('wg*') is currently basically a wrapper for window.wg*. To make
such deprecation notices possible we'd have to duplicate the values, which
could cause them to get out-of-sync if something modified them after page
load.Is this an actual issue? Once they are set, they shouldn't be changed anyway.
So using a new object for mw.config.values instead of window and copying the
variables over when they are set the first time using mw.log.deprecate
shouldn't break more than replacing some of the wikibits.js functions with
$.noop will break.
Apparently VisualEditor sets one, see bug 56532.
Comment Actions
I just tried, and found that mw.log.deprecate can be called multiple times for the same variable without any problems. So mw.config.set could just call it, and whenever a wg* variable is changed via mw.config.set the global value would be updated, too. Only the other way round wouldn't work (or require some extra code instead of mw.log.deprecate).
Comment Actions
Change 133162 had a related patch set uploaded by Gerrit Patch Uploader:
Show deprecation notices when accessing wg* JavaScript globals
Comment Actions
Change 133162 had a related patch set uploaded (by Krinkle):
mw.config: Show deprecation notices when accessing globals
Comment Actions
Change 133162 merged by jenkins-bot:
mw.config: Show deprecation notices when accessing globals