Author: mike.lifeguard+bugs

Description:
Copied from http://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard&oldid=19396943#Javascript:

Our current setup with Javascripts has the problem that errors in one script may prevent other scripts from working. Most of our scripts (gadgets and others) work by registering a function that is to be executed once the main part of the page has been loaded. If there are several scripts (gadgets or others) active, they each will register their own function. These functions will then be run in the order they were registered once the page is ready.

The problem with this is that if one of these registered functions has an error and crashes (raises an exception), those functions that were registered later won't be run at all. That can have hard-to-track and usually unwanted effects.

Lupo has added to Commons' MediaWiki:Common.js such that exceptions from these "onload" functions get caught. That code catches such exceptions and logs them, thereby making sure that all registered functions get called even if some of them fail.

The question now is where to log these errors, and who should see them. Currently, that code tries to log them to the browser's "error console", if possible, and displays the errors on the page only if that fails or if the user viewing the page is a sysop. (That's based on the assumption that sysops are typically the only ones who can do something about JS errors, since most of our scripts reside in protected pages anyway.) Non-sysop users would see these errors only if their browser had no "error console". But I could just as well suppress error messages for non-sysop users completely, or suppress them for anyone by default and show them only for users who put a certain flag in their monobook.js.

The code was tested on IE6 (alas, no source info), FF3.0.7 with Firebug 1.3.3, Safari 3.2.2 (Webkit 525.28.1), Opera 9.6.3. When people complain about strange things that might be connected with our JavaScript (such as gadgets not working or not having a category bar on the upload form), tell them to look at the top of the page whether there's some error message there.

Of course, ideally, one would fix this in wikibits.js directly. They should have written the onload hook handling from the very beginning such that it doesn't break when one hook fails. Wikibits could also give us a better jsMsg, and addPortletLink could be written such that it also works on the old skins (see e.g. function addToolLink in MediaWiki:Utilities.js). It could also offer a very minimal set of common JavaScript enhancements (such as String.trim or Function.bind, and other simple commonly used and often re-implemented stuff). But frankly said, I have no patience. Getting a change into wikibits means opening a bugzilla "enhancement" bug report, and these get low priority. If something like this ever goes into wikibits, great. But I wanted it now.

Version: 1.15.x
Severity: normal
URL: http://commons.wikimedia.org/w/index.php?title=MediaWiki:Common.js&diff=19380030&oldid=18916605