Page MenuHomePhabricator

Native editButtons can't be removed or reordered through r86603
Closed, DeclinedPublic

Description

Author: a.d.bergi

Description:
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 http://de.wikipedia.org/wiki/MediaWiki:Gadget-Extra-Editbuttons.js, 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.

Version: 1.18.x
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23624
https://bugzilla.wikimedia.org/show_bug.cgi?id=64745

Details

Reference
bz28681

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:38 PM
bzimport set Reference to bz28681.

Putting bug back in Javascript component (it's not RL-related) and assigning to DieBuche, who caused the breakage.

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

matmarex claimed this task.

Indeed, this isn't supported these days. Sorry.