Forms Sizing need to avoid scroll bars when not called for

[sjpadgett]

Good case in point is encounter tabs. i.e

Inner scroll is unnecessary. This will cause problems for touch devices unless prevented with purpose.
This is one of the reason which i've spoken for our top patient info bar being a known height. Speaking off, there is still a lot of real estate in that top bar. I still say if somebody doesn't want condensed then all other areas of app can be full but top bar is always a known height (condensed)
This is how it should be:

Guessing everybody is thrilled i'm sort of back! This may seem trivial but I promise it's not...

[bradymiller]

I am thrilled you are back!!!

[tywrenn]

This should be an issue that my BS4 branch addresses since I've been working with tab/height structure in it. We should be converting to a more uniform modal structure as well (some are the old structure and some are using BS4 modals which looks odd).

We could possibly use the fix that I did with the patient portal registration step 2 frame area where the height was detected via a script inside the frame and the page adjusted it accordingly. Only issue is this method requires us to go through every single modal popup ever created and add the code in. Probably could do this more easily by creating a PHP file that allows us to one-line this code. This is the best approach that will make detection easy.

We could also use my jQuery height fix that I did on my branch that figures out the height from jQuery. This method makes it so you don't have to add the script to all the modals yet you still have to add it to the area in which the modal is triggered.

[Devvyky]

@sjpadgett how do I recreate this same issue?

[tywrenn]

@Devvyky This can be recreated in a few ways:

1. If you are on a mobile device and a page gets cut off for no reason (e.g. calendar)
2. On certain pages if you are trying to resize them the scrollbar messes up

Also we should not have a scrollbar on certain modals that we are using (e.g. adding a new event to the calendar). I'm not sure how to fix modals though (they are really tough to fix).

[stu01509]

Hello @bradymiller @tywrenn and @sjpadgett

Is now the problem solved or anyone is working on this issue?
If not, I will try to fix it, Please assign this issue to me.

[bradymiller]

I am willing to bet this issue was resolved with all the prior bs4 changes. Recommend testing it, though, to confirm.

[stu01509]

@bradymiller Thanks for your notice, I will take a look 😃

[stu01509]

Hello @bradymiller @tywrenn and @sjpadgett

I reproduce the issue on Chrome, Seems like it didn't fix. Do you have any idea or suggestion for me to solve it?

Now, I created a PR #3352, I used inner style overflow-y: hidden; to prevent inner scrollbar, Is good a solution?

[sjpadgett]

Just revert and leave alone please.

[bradymiller]

hi @sjpadgett , Is there no solution for this issue then?
(looks like we made the change on the wrong script here)

[sjpadgett]

It is fixed in encounter. You never should need to add overflow style to html tags but where container is created. You'll never get dynamic viewport sizing consistent across all browsers and devices imo. I learned this from auto sizing dialog.
Retest encounter as I put a fix in awhile back. Same fix I used since 501...

[stu01509]

Hi @bradymiller and @sjpadgett

Should I continue to solve this issue?

[sjpadgett]

@stu01509 I fixed this I believe.
First the issue was with the tab summary container scroll not inner scroll. The fix is in the Tabs Summary when container is created.

I'll close this issue but feel free to try different solution if ya want but, i'm keeping an eye on this and will test more as I go.
Thanks