Last modified: 2014-09-19 23:18:15 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 T69481, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 67481 - mw.trackSubscribe should prevent infinite recursion
mw.trackSubscribe should prevent infinite recursion
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: High normal (vote)
: 1.24.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-03 16:14 UTC by Brad Jorsch
Modified: 2014-09-19 23:18 UTC (History)
8 users (show)

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


Attachments

Description Brad Jorsch 2014-07-03 16:14:34 UTC
Bug 67420 was apparently caused by a deprecation warning from inside the handler that attempts to log deprecation warnings. While Gerrit change #143894 should fix the immediate problem in that bug, it would probably be a good idea for ext.wikimediaEvents.deprecate.js to bail out when called recursively to avoid a repeat next time.
Comment 1 Bartosz Dziewoński 2014-07-03 16:18:26 UTC
Detecting recursive calls might be difficult, but it can just suppress all warnings. From /tests/qunit/data/testrunner.js in core, these functions are used several times in tests:

	var warn;

	function suppressWarnings() {
		warn = mw.log.warn;
		mw.log.warn = $.noop;
	}

	function restoreWarnings() {
		if ( warn !== undefined ) {
			mw.log.warn = warn;
			warn = undefined;
		}
	}
Comment 2 Krinkle 2014-07-03 22:00:09 UTC
The high priority bug was bug 67420 which has been fixed.
Comment 3 Bartosz Dziewoński 2014-09-19 15:50:20 UTC
Actually, I don't see any way to implement this, given that everything can be asynchronous. I might be missing something, but this seems impossible.

We can implement some half-solutions (only guarantee detection of this scenario when both the track handler and everything it does is synchronous; stop sending further tracks after some limit is reached;), but they would be prone to failure and could instill a false sense of confidence.

There is a (conceptually) very simple way to avoid this: don't use deprecated APIs in your mw.track handler.

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


Navigation
Links