@Mooeypoo As our resident OOUI expert, your thoughts on this ticket are welcome.

That's actually pretty complicated. We have a couple of tasks about similar issue with pop-ups that we need to fix in ooui. It has to do with changing the logic of popup widget and clippable and its a bit of a mess.

However, we can fix this bug somewhat by having the date popup appear in another overlay on top of the overlay that windowmanager gives us. We did this for rcfilters and in Echo sub menus. It will at least make sure that the date popup isn't cut off by the bottom of the dialog, and is pretty quick to do.

@Mooeypoo So IIUC, the date popup will extend outside the dialog instead of being cut off on the inside? That works for me.

Yep. If you look at the Echo popup and try to open a sub menu (dotdotdot) at the lower end, you'll see it opens downwards but isn't confined by the general popup.

That will be what we can do to the date picker, plus it will be always on top, not hidden by the following fields.

Change 444261 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/extensions/TemplateWizard@master] Add a popup overlay and set it up for field popups

https://gerrit.wikimedia.org/r/444261

@Mooeypoo your patch gives me this:

because the .mw-widget-dateInputWidget-calendar has a z-index of 1 I guess... I'm trying to track down why it's getting the bottom scroll bar (it shouldn't ever, should it?).

In T198931#4418528, @Samwilson wrote:

@Mooeypoo your patch gives me this:

because the .mw-widget-dateInputWidget-calendar has a z-index of 1 I guess... I'm trying to track down why it's getting the bottom scroll bar (it shouldn't ever, should it?).

eek... that shouldn't happen, even with the z-index, the calendar lives inside an overlay that has a high z-index :\

Also, I am not getting this on my computer. What browser are you seeing this on? Is it only when the calendar is the last parameter?

Same thing in Chrome and Firefox, and no it doesn't matter where in the list the field is. The calendar popup is obscured behind the dialog:

I found the culprit and fixed it; the WindowManager has z-index set for 101; I set the popup overlay to be 110. It works for me now.

There could be an issue with the overlay: when the date field is at the bottom of the screen when there's no scroll bar, it can extend off screen and can't be reached:

With patch:	Without patch:

(Ignore the horizontal scroll bar, that's a separate issue I think.)

This could be somewhat mitigated by the other task to make the dialog smaller -- the odds of the calendar popup, even if it's at the bottom of the dialog, reaching the bottom of the window would be a lot smaller.

Oh, good point. At the moment we're just giving it 100 pixels. And all other popups would be okay wouldn't they? The file- and page-selection ones, I mean. They just get smaller if they don't have room (and they seem to behave better about popping up to the top when required).

Yeah, I flagged this behavior to @Niharika when I worked on it, and she mentioned making the dialog smaller, which would probably make things better. It's not the best solution because OOUI needs to flip the popup around, but it doesn't right now (there's a pending task for this for ages now... highly requested feature)

This only seem to mostly affect the calendar that has "rigid" dimentions -- as you point out, the other popups (file/page selection) are using "clippable" which means they are changing their height based on the container they're in. With the current change, they'll be confined to the window instead of the dialog, which might actually be better for these widgets specifically.

This problem should be fixed when we do T198920: Switch TemplateWizard dialog to smaller size. Let's re-evaluate once that is done. We might still run into issues on smaller devices.

Change 444261 merged by jenkins-bot:
[mediawiki/extensions/TemplateWizard@master] Add a popup overlay and set it up for field popups

https://gerrit.wikimedia.org/r/444261