Page MenuHomePhabricator

OOUI non-modal windows and dialogs miss default CSS
Open, Needs TriagePublic

Assigned To
None
Authored By
WMDE-Fisch
Apr 26 2017, 11:36 AM
Referenced Files
F34443374: image.png
May 6 2021, 10:50 AM
F34443366: image.png
May 6 2021, 10:50 AM
F7779419: TwoColConflict dialog.png
Apr 26 2017, 3:56 PM
F7779172: image.png
Apr 26 2017, 3:24 PM
F7779117: image.png
Apr 26 2017, 3:24 PM

Description

I don't know if this is intended, but it seems that when you use the OO.ui.WindowManager with the modal: false setting and e.g. a OO.ui.Dialog there are no default styles for the generated non-modal CSS classes in the oojs-ui-windows-mediawiki.css

So for example there are styles for

.oo-ui-windowManager-modal > .oo-ui-dialog > .oo-ui-window-frame {
  background-color: #fff;
  opacity: 0;
  -webkit-transform: scale(0.5);
  -moz-transform: scale(0.5);
  -ms-transform: scale(0.5);
  transform: scale(0.5);
  -webkit-transition: all 250ms;
  -moz-transition: all 250ms;
  transition: all 250ms;
}

But there is nothing for
.oo-ui-windowManager > .oo-ui-dialog > .oo-ui-window-frame

Event Timeline

Non-modal windows are a weird beast. I can't say if this was a good decision, but it is intentional, due to how non-modal windows were used in VisualEditor. For example, the "Special character" tool in VisualEditor is actually a non-modal window:

image.png (968×1 px, 325 KB)

Same with "Find and replace":

image.png (968×1 px, 375 KB)

Looking at the patch on T162147, it seems like you want a "normal" dialog that doesn't block interaction with other things on the page? Out of curiosity, can you upload a screenshot of how it looks?

We did nothing to allow this mostly because right now it's impossible to move or hide the dialog (T51969), so it would still block interaction with whatever it happens to cover. And someone was probably worried that it would confuse mobile users.

Hey @matmarex,
thanks for your comments and the clarification. You're right I need(ed) this in T162147. Because I just wanted to block the interaction with the editor and not with anything else. So I ended up using a non-modal window manager showing the dialog above the editor with some ( probably hacky ) CSS to position it right. See the screenshot below:

TwoColConflict dialog.png (768×1 px, 165 KB)

( The blur is something I added manually to the editor textarea as you can see in the patch )

Volker_E renamed this task from OOjs UI non-modal windows and dialogs miss default CSS to OOUI non-modal windows and dialogs miss default CSS.Jan 17 2018, 12:48 AM

So it turned out non-modal OOUI doesn't have any of CSSs modal one has to make a correct dialog anyway,

Compare

(function () {
    function Dialog(config) { Dialog.super.call(this, config); }
    OO.inheritClass(Dialog, OO.ui.ProcessDialog);
    Dialog.static.name = 'dialog';
    Dialog.static.title = 'Test Dialog';
    var windowManager = new OO.ui.WindowManager();
    $(document.body).append(windowManager.$element);
    var dialog = new Dialog();
    windowManager.addWindows([dialog]);
    windowManager.openWindow(dialog);
}());

image.png (238×1 px, 16 KB)

with

(function () {
    function Dialog(config) { Dialog.super.call(this, config); }
    OO.inheritClass(Dialog, OO.ui.ProcessDialog);
    Dialog.static.name = 'dialog';
    Dialog.static.title = 'Test Dialog';
    var windowManager = new OO.ui.WindowManager({ modal: false });
    $(document.body).append(windowManager.$element);
    var dialog = new Dialog();
    windowManager.addWindows([dialog]);
    windowManager.openWindow(dialog);
}());

image.png (270×840 px, 54 KB)

(the dialog appears in whole unexpected place)

I've used done a migration jquery.dialog transition to OOUI of an important tool of our wiki and am asked why one can't click outside of the dialog just as described in https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.WindowManager-cfg-modal which apparently is untested and broken.