https://bugzilla.wikimedia.org/show_bug.cgi?id=18039

           Summary: onload hook handling shouldn't break when one hook fails
           Product: MediaWiki
           Version: 1.15-svn
          Platform: All
               URL: http://commons.wikimedia.org/w/index.php?title=MediaWiki
                    :Common.js&diff=19380030&oldid=18916605
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: General/Unknown
        AssignedTo: [email protected]
        ReportedBy: [email protected]
                CC: [email protected]


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.


-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to