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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30681, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28681 - Native editButtons can't be removed or reordered through r86603
Native editButtons can't be removed or reordered through r86603
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.18.x
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: ---


Attachments

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 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.
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.
https://gerrit.wikimedia.org/r/#/c/16238/2/resources/mediawiki.action/mediawiki.action.edit.js

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


Navigation
Links