Last modified: 2012-05-11 18:30:11 UTC
In your prefs turn off the enhanced editing toolbar, then go to the edit interface for an article. Hit reload a few times. Eventually you'll see that about half of the edit buttons are periodically missing from the page. This has apparently been happening for several weeks now according to the Village Pump. It sounds like a race condition and could potentially be related to the RefToolbar which is loaded from http://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js (and includes lots of very old JavaScript).
Looks like it's not related RefToolbar, as disabling RefToolbar doesn't fix the problem.
This seems to be related to the mwCustomEditButtons code on http://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js.
It looks like there's a race condition between mediawiki.action.edit.js and http://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js (which is loaded from MediaWiki:Common.js). In theory, mediawiki.action.edit.js is supposed to load after MediaWiki:Common.js/edit.js. mediawiki.action.edit.js is loaded on document.ready, while MediaWiki:Common.js is loaded via mw.loader.using( 'mediawiki.util', function() {}.
Looks like moving importScript('MediaWiki:Common.js/edit.js'); outside of mw.loader.using( 'mediawiki.util', function() {} doesn't fix the problem, but loading the mwCustomEditButtons code directly in MediaWiki:Common.js rather than via importScript('MediaWiki:Common.js/edit.js') does fix the problem. The downside is that we would then be downloading this extra Javascript code on every page view, which would consume more bandwidth. Does anyone have any other ideas? Is there any way to make MediaWiki:Common.js a dependency of the 'mediawiki.action.edit' ResourceLoader module?
(In reply to comment #3) > It looks like there's a race condition between mediawiki.action.edit.js and > http://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js (which is loaded from > MediaWiki:Common.js). In theory, mediawiki.action.edit.js is supposed to load > after MediaWiki:Common.js/edit.js. > The problem is a simple one. When taken as-is, the answer is simple. It can't be fixed. The global variable mwCustomEditButtons is just a variable. It can't be "hook"'ed into for changes. Either one checks it in time or it is checked too late. To my knowledge this has always been an issue, for as long as the classic toolbar exists. Users have always been struggling with load event handlers to time it just right for their own browser. The only way to fix it is to not use the (now deprecated) mwCustomEditButtons variable but the new (well, not very new anymore) mw.toolbar object instead. See also bug 33952 and related bugs. I've already informed en.wikipedia in the past about this: * https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js/edit.js#MediaWiki:Common.js.2Fedit.js:_Opt-out * https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js/edit.js#MediaWiki:Common.js.2Fedit.js:_mw.toolbar.addButton *** This bug has been marked as a duplicate of bug 33952 ***
Also note that: * Don't confuse mw.toolbar.addButton with the WikiEditor API. mw.toolbar is 100% compatible with mwCustomEditButtons. As a matter of fact, the mw.toolbar module is what checks and processes the values in mwCustomEditButtons. mw.toolbar.addButton has a check to make sure that if the button is added to early, it will be put into a queue so that it is inserted into the toolbar as soon as the toolbar is detectable. And if it is inserted "too late", it will be added on-demand.
I didn't even know mw.toolbar existed. It isn't mentioned anywhere on MediaWiki.org. I'll try to add some documentation for it one day.
Nevermind, I found it: http://www.mediawiki.org/wiki/Manual:Custom_edit_buttons
I fixed the code on en.wiki and updated the documentation.
