Last modified: 2014-09-05 22:44:44 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 T58550, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 56550 - Show deprecation notices when accessing wg* JavaScript globals
Show deprecation notices when accessing wg* JavaScript globals
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.23.0
All All
: Low enhancement (vote)
: ---
Assigned To: Fomafix
:
Depends on:
Blocks: 33837 70470
  Show dependency treegraph
 
Reported: 2013-11-04 09:46 UTC by Michael M.
Modified: 2014-09-05 22:44 UTC (History)
9 users (show)

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


Attachments

Description Michael M. 2013-11-04 09:46:22 UTC
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.
Comment 1 Bartosz Dziewoński 2013-11-04 10:29:02 UTC
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 2 Brion Vibber 2013-11-04 18:08:27 UTC
Hm, how would deprecation actually work? Can we add getters on the window object?
Comment 3 Michael M. 2013-11-05 08:55:34 UTC
(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 4 Ltrlg 2013-11-05 18:57:20 UTC
(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 5 Michael M. 2013-11-07 09:37:04 UTC
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 6 Helder 2014-03-07 23:34:14 UTC
mw.log.deprecate warnings are now visible when not in debug mode too.
Comment 7 Gerrit Notification Bot 2014-05-13 20:37:13 UTC
Change 133162 had a related patch set uploaded by Gerrit Patch Uploader:
Show deprecation notices when accessing wg* JavaScript globals

https://gerrit.wikimedia.org/r/133162

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


Navigation
Links