This is the talk page for discussing improvements to the Modal page.

Scrollbar bug

Hey Kocka,

I just checked your examples out but when I closed a modal, the scollbar disapperead so I couldn't scroll the article anymore.

Best regards
Agent Zuri Profile Message Wall Blog 18:07, April 30, 2019 (UTC)

This should be fixed now. -- Cube-shaped garbage can 07:23, September 21, 2019 (UTC)

How do I use this?

I have a rather limited understanding of JavaScript, and after reading the documentation, I am still confused about certain parts.

First of all, I don't understand how to use the hook

mw.hook('dev.modal').add(function(modal) {
    // `modal` object is the library's
    // exported object, same as

What do I put inside the function, or do I just leave it empty? Where do I put this in my code?

Also, how can I show the modal? After creating the modal, I've tried attaching create() and show() to an event, but that did not work.

$("div").click(function() {

It would be wonderful if anyone can help me!—YXTQWFclimbTheStairs 11:30, March 29, 2020 (UTC)

When you import the library via importArticle/importArticles the library isn't immediately available, as it needs to load and execute first, so you won't be able to use it straight after the import statement. That's why it fires a hook via MediaWiki's mw.hook system that you can listen on for when the library has finished loading.
The modal is best created right after you instantiate it, as creating it in an event listener will delay its showing. So basically, you can do:
// This declares the variable you will use for storing the
// instantiated modal.
var m;

// This sets the hook.
mw.hook('dev.modal').add(function(modal) {
    // Now the library has loaded, instantiate your modal.
    m = new modal.Modal({
        // Contents of this object are documented on [[Modal#Parameters]]
        // and examples can be found below.
        content: 'This is your modal content',
        size: 'medium'

// This sets the click event listener on your element.
$('#yourselector').click(function() {
    if (m) {
        // Show the modal if it was instantiated.;
    } else {
        // Modal has not been instantiated yet.
        // To avoid this situation you can also not set the event
        // listener until the modal has been instantiated.

// This imports the Modal library.
    type: 'script',
    article: 'u:dev:MediaWiki:Modal.js'
Does that make it more understandable? -- Cube-shaped garbage can 13:35, March 29, 2020 (UTC)
Yes! Thank you so much! Can I import it with ImportJS instead?—YXTQWFclimbTheStairs 21:28, March 29, 2020 (UTC)


I was using this script to create modals:

(function() {
    var m;
    mw.hook("dev.modal").add(function(modal) {
        m = new modal.Modal({
            id: "testing",
            size: "medium",
            content: "",

However, a bug occurred; whenever I open and close any of Fandom's modals (e.g. preview, kudos, etc), the scrollbar would disappear, and it would not reappear until I close the modal created by my script, even though it was never opened.

It turns out that this was because the scripts AjaxBatchDelete and MassEdit were imported on that wiki. Both of those use Modal, so why do they conflict, and what can I do to fix this?YXTQWFclimbTheStairs 23:12, June 11, 2020 (UTC)

I've done some more testing and this bug has nothing to do with those scripts. Whenever I use Modal, the scrollbar will disappear after I open and close any modal not created by this script.—YXTQWFclimbTheStairs 05:10, June 17, 2020 (UTC)


Are there plans to UCPify Modal in the near future? Both the oojs-ui-core and oojs-ui-windows ResourceLoader modules and the associated MessageDialog and WindowManager classes are readily available for use on UCP wikis, so perhaps an OOUI/OOjs-based dialog implementation could be employed as a short-term modernization until either wikia.ui.factory is ported over or an alternative implementation is developed. EIZEN (talk) 15:12, July 30, 2020 (UTC)

Yes, I'm planning to port this to UCP in the near future (using, as you mentioned, OOUI). -- Cube-shaped garbage can 15:14, July 30, 2020 (UTC)

setContent TypeError

Hey Cube, thanks for updating Modal. I noticed that attempts to dynamically invoke Modal.prototype.setContent on existing Modal instances throw Uncaught TypeError: this._modal.setContent is not a function exclusively on UCP wikis. I haven't perused Modal's code in any real detail, but I believe this error is due to the fact that the _modal property of the Modal instance has setContent as a method of its prototype chain on legacy wikis but not on UCP wikis. I know your edit summary stated that not all functionality is currently supported, but I just wanted to mention this behavior in case you weren't aware. Cheers! EIZEN (talk) 22:20, August 18, 2020 (UTC)

Thanks! That error should no longer be happening, though Modal currently doesn't really support setting the content on the modal after its creation (I will look into supporting this later). -- Cube-shaped garbage can 14:17, August 22, 2020 (UTC)
Really? Well, it's been performing flawlessly for MassEdit for quite some time. Due to the sheer amount of functionality that script supports, its UI would be difficult to navigate without the ability to compartmentalize functionality into dedicated interfaces. Modal.prototype.setContent has proven to be an excellent mechanism by which modal content can be dynamically changed post-creation depending on the interface the user wants to use. Anyway, thanks for the fix! EIZEN (talk) 14:52, August 22, 2020 (UTC)
Ah, I meant that it wasn't supported on UCP. Since it's blocking porting of MassEdit I've made that feature available on UCP now too. -- Cube-shaped garbage can 16:35, August 22, 2020 (UTC)
I was just about to report this, but noticed it's not only been reported but the change is currently under review; thanks for adding support for this! Since when using this script we have to reuse the modal, not having this feature would have been awkward. Fewfre 🔎 K🧀20:15 Sat, 22 Aug 2020

Close event

I think there are two issues related to closing relating to UCP; a) "_close()" / "closeFunc()" does not appear to be called at all during UCP part of the code (meaning the "close" callback is never triggered), and b) if you give a button the event "close" it doesn't seem to work on UCP, but does on older wikis. Currently getting around this by making a custom close event. Fewfre 🔎 K🧀00:26 Sun, 23 Aug 2020

The close event not being handled should have been fixed in Special:Diff/138655 and it's working in AjaxBatchDelete for me, are you using the latest version of Modal? -- Cube-shaped garbage can 13:26, August 23, 2020 (UTC)


Thanks again for the updates, Cube; sorry to keep pestering you with these issues.

Per the latest approved version, was the appending of the "Cancel" button handling the close event to the modal header intentional? It seems wildly out of place up there. Additionally, it seems certain other buttons previously located on the footer are now randomly appearing in the header as well. To use AjaxBatchDelete as an example, the "Initiate" button is now located in the header for me, and I'm seeing similar behavior appear in my personal development copy of MassEdit with the "Submit" button. Is there a config option to reverse this and return the buttons to the positions they previously occupied on the modal footer?

Additionally, there doesn't seem to be a clean way to opt out of the inclusion of the default "Cancel" button in the buttons array, since it is pushed to the end of the array on all UCP wikis. MassEdit already has a button dedicated to the close event in its UI, so I don't really need a duplicative button. My current hack is simply to pop() the default "Cancel" button off the array prior to invoking Modal.prototype.create, but that seems really messy. Is there some sort of config option permitting the use of the close event but the exclusion of the button?

Finally, just for planning purposes, are there plans to support the disabling of buttons span pseudo-buttons on UCP wikis? No rush if that's on the agenda; I just wanted to check with you so I didn't sink too much time into that myself needlessly. Cheers! EIZEN (talk) 18:47, August 24, 2020 (UTC)

Sorry for the late response.
Yeah, appending the cancel button to the header was an intentional result of specifying the close flag on that button, and since there are by default no close buttons on the modal one is automatically added to it. I plan to add an option to disable this behavior later. (On vanilla MediaWiki 1.35 OOUI buttons with the close flag automatically convert to an X, but that is not the case on Fandom apparently.)
Buttons marked as primary are also appended to the header as a result of specifying the primary flag. This is OOUI behavior that I won't be changing in Modal, but you can not specify the primary flag if you don't want the button to appear in the header. (In the context of a process, as Modal windows on the UCP are ProcessDialogs, it makes sense for a button that advances to the next step to be located in that position.)
As for disabled buttons, I apparently used the wrong ActionWidget property for disabling buttons, so if your last question was about the disabled option, that should be working after the latest revision is approved.
Cheers! -- Cube-shaped garbage can 15:39, September 7, 2020 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+