I’ve experienced this issue on my main app, but re-produced it in a new app just to confirm the issue wasn’t related to my app config. If you open a card modal with height of auto and scrollable true, with contents larger than the mobile devices screen height, it will scroll erratically. You can see this behavior yourself by clicking the Modal button here: https://dansmith65.fmbetterforms.com/
I think this is an issue inherent to something in BetterForms since the issue does not exist on http://vue-js-modal.yev.io when using the Demo: Width: 60%, Height: auto button.
Items to note in the video:
I’m scrolling down slowly, but when I release, it jumps to the bottom of the window.
After that, I can never scroll to the very top of the form again
I think this is a high priority issue because it renders modal windows larger than the screen unusable. Depending on the settings used, users could be stuck on the modal with no way to close it.
Hmm, I think what you can do is not rely on the modal to support the scrolling and just scroll the modals page’s body
What formType is the card modal form?
The new 'formblank` type supports two new keys:
styleClassesPage - classes are applied to the outermost div of the page styleClassesBody - classes are applied to the pages body, in the event you are using a form header slot, this allows better targeting.
I have this issue on various forms with various form types. This example I referenced used the default app template, so it used formplain.
Note that tailwinds h-screen, which applies css 100vh doesn’t work well on a mobile browser by itself either: The trick to viewport units on mobile | CSS-Tricks. By default, that solution will crop the bottom of the content if the user hasn’t (or can’t) scroll the address bar out of view.
I checked the event listeners on that object and found an onWindowResize handler that runs a function in vue-js-modal. Going back to my original post, this isn’t an issue on http://vue-js-modal.yev.io, so I’m wondering if BetterForms is using an older version of that library where this bug still exists, but perhaps it’s been fixed since then?
That message appears to be outdated now that 2.0.1 is released. That said, 2.0.1 was only released a few months ago, but it also has 115k weekly downloads, so I suspect it’s fairly well tested