Last modified: 2014-08-26 03:49:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 28681 - Native editButtons can't be removed or reordered through r86603
Native editButtons can't be removed or reordered through r86603
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: DieBuche
Depends on:
Blocks: edit-toolbar
  Show dependency treegraph
Reported: 2011-04-24 14:03 UTC by Bergi
Modified: 2014-08-26 03:49 UTC (History)
7 users (show)

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


Description Bergi 2011-04-24 14:03:54 UTC
I'm not sure whether to file this bug in JavaScript or PageEditing Component, or even in Extension:Gadgets. Feel free to change :-)

Before r86603 there was a public variable mwEditButtons which every script could access and change. It was initialised in wikibits, which also created the onloadHook with the common used addOnloadHook() function.
After that (with RL managed through its depencies) edit.js created another hook for its mwSetupToolbar function, in which the buttons were append to the document.
So in between various gadgets and userscripts could change mwEditButtons and mwCustomEditButtons. For example, there is, which even has to wait with its initialisation for config from userscripts. This can be easily done because the onloadHookFuncts are run before the event for mwSetupToolbar is triggered. Such personalisation is often desired, see Bug 14530.

But now the inline script directly adds the buttons to the document, so userscripts can't access them any more and will have to remove them from the DOM. Also, there is no function hook that is called after any config script (the addOnloadHook) but before the various direct $(document).ready calls, in here the inserting of the buttons (mw.toolbar.init();).

So I propose a more public interface like mw.toolbar.buttons of type array, which can be changed directly or by mw.toolbar.addButton(). In the init function it is concatenated with the window.mwCustomEditButtons (for legacy), before the buttons are generated and inserted into the document.
That also means that the inline script does need no $(document).ready wrapper any more; the onDOMready for the init function should be done right in action.edit.js.

I see three solutions for the addOnloadHook problem:
* just moving the buttons.init-function to the end of the ready-stack by calling it nested in itself.
* second: a mw.toolbar.hook array of functions, which are called before initing the buttons
* third, much better but much more severe: A new general onLoadHook, which is called before the normally used $.ready-events. This had to be done at the initialisation of window.mediaWiki. It also could solve lots of similiar problems.
Comment 1 Roan Kattouw 2011-04-25 18:29:53 UTC
Putting bug back in Javascript component (it's not RL-related) and assigning to DieBuche, who caused the breakage.
Comment 2 DieBuche 2011-04-26 10:13:07 UTC
Fixed in r86942.
mw.toolbar.buttons can be modified to your heart's content, it's written out on document.ready.
mw.toolbar.buttons is filled immediately, so you don't need to wait for it.
If addButton is called after doc.ready, the button is *immidiately* added to the DOM
Comment 3 Helder 2014-08-26 03:44:07 UTC
The array mw.toolbar.buttons was removed again on Gerrit change #16238.

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