Set overflow of plugin dialog (or form) to auto or scroll for cases where it is on a small screen.
Steps to reproduce
Create a very tall dialog and open on Windows. Or shrink the size of the main application window and then open a plugin.
Part of the plugin (on Windows) will be cut off.
Expected
Scroll bars appear when needed
Actual
Content is cut off
Somewhat related: The option to be able to set a max-height for dialogs such that they don’t overflow on small windows of XD would already help a lot. Currently, there is no real “safe” height which we can use on dialogs so that we can’t even manually use overflow (since we can’t really use any height, allowing for a useful scrolling functionality in the first place 
).
If that gets added by default or if I have to add some own CSS really wouldn’t matter to me (it wouldn’t hurt, but it’s not important to me). So I’ve voted for having the ability to use an useful overflow behavior (may that be enabled by default or not).
Hmm… If you are on OSX the dialog grows in size to fit the content even if it extends past the height of the application or screen.
On Windows the dialog is sized to the height of the content OR the height of the main application window whichever is smaller. Any content that does not fit is clipped inside the dialog (NET - not extensively tested).
I’ve added overflow auto to the main form and then set the height of some elements in the form to an excessive amount and also set a height smaller than the content on the form and it’s showing scroll bars.
The changes I made will only affect the Windows side of things so I also reduced the height of the form to shortest height possible for the OSX side.
BTW When you resize the main application scroll bars appear automatically in various parts of the application.
So, the intent here would be to allow overflow: scroll or overflow: auto to work as expected, I think. However, because of a bug where the dialog height isn’t properly reported, the system doesn’t know to apply a scrollbar. Definitely a bug, and something we’ll be working on fixing. 
On Windows, XD is already setting a max height. The height of a dialog is limited to the height of the main application. Maximize the application and the dialog has a greater max height. This is different than in OSX where the dialog is sized to whatever the content is.
So in Windows you would want a min height. Because if you say, this is the minimum height I need then a container that resizes to available space will say, if the form must be at least this high and the space available is less than that, then clip (current behavior) or add scroll bars. A min height would do the same as manually setting the content height.
@kerrishotts Can the differences in dialogs be converged or are their OS specific limitations?
I’m not usually one to ask if there are any updates on a feature request, but this is one of the rare cases I do. I’m currently dealing with having a dialog with variable length (based on how much configuration is required) – i.e. I can have 1…6 input areas below each other. Having no reliable way to deal with the overflow is pretty inconvenient since especially on Windows, content simply gets cut off without any way to reach the CTA button at the bottom.
Especially with the default XD window being extremely small on Windows for every new document (see my complaints here 
), the minimum dialog height would be far too small (and I couldn’t fit anything in there) since the default window is so tiny. On the other hand, if I assume that “default” height as minimum height and make my dialog fixed on that height, this will simply look stupid on bigger screens (or even on maximized windows on small screens) since this window size XD resets to is really small 
I’m restraining myself from tagging anyone here, but just wanted to comment on it to ask if there’s an update on it and possibly add some visibility to this again since – with the last comment being from January – this was pretty much invisible in the forums right now (I didn’t find it without the search bar – while that’s pretty subjective, it can’t hurt to get this request to the top of the topics to get some visibility to it since, as @kerrishotts has confirmed above:
PS:
I love how the forum proves my point about this topic being kind of old 
:
@stevekwak the workaround I use is to multiply the viewport height by the zoom factor as a way of estimating the window height:
import viewport from 'viewport';
const viewportHeight = viewport.bounds.height * viewport.zoomFactor;
and then use that to set the height style property of the dialog.
You can stop there, but I also wanted to make some CSS properties grow and shrink proportional to that height and to not have to do that all in JS. So, in case you find it useful, what I ended up doing was creating a CSS variable --viewport-height, setting it to the viewportHeight from above and using it like this: --component-width: calc(var(--viewport-height) * 0.56);.
To do this, I used https://gist.github.com/nemtsov/39f6bfaa235800892f916dafdd57f78f (updateCssStyle function). So assuming my CSS started with:
.my-container {
--viewport-height: 375px;
--component-width: calc(var(--viewport-height) * 0.56);
}
.my-container .component {
width: var(--component-width);
}
The function to update that variable was:
updateCssClass(
'my-container',
`--viewport-height: ${viewportHeight}px;`
);
FYI On Mac the scroll feature is working for me in the panel when applying it to the form (have to double check on Windows).
I’m setting the form to overflow to auto. Pseudo code:
<form style="overflow:auto;width:200px;"></form>
On one form I’m setting vertical scroll bars only with:
<form style="overflow-x:hidden;overflow-y:auto;width:200px;"></form>