QDialog [ios] [ipados] Keyboard is overflowing inputfields on Dialogs

ibrainventures commented 4 years ago

Dear Team,

that is my major issue on the QDialog. If you open a standard Dialog and there is a Input Field the virtual Keyboard overflow the entry-fields.

So no entry is possible .. Scrolling to the fields else is also prevented.

With the seamless Option, the entries are possible, but the scroll / overall handling of that seamless Dialog is awkward (Background-Scrolling etc.)

For Testing there is a Sandbox:

https://vtft7.sse.codesandbox.io/ e: https://codesandbox.io/s/codesandbox-app-vtft7

If you make a slow motion .. you will see, that standard Dialog scrolls short up - but it snaps down ..

That it is possible, to have a working Dialog with Input on ios Devices, you see on my codepen:

https://codepen.io/ibrainventures/full/eYYBdRE e: https://codepen.io/ibrainventures/pen/eYYBdRE

(here the Dialog is NOT snapping down - opened in an non seamless Dialog)

May the reason that it is working there (same Dialog Code) is, that the codepen wrapper is blocking some dyamic body-attaches by the quasar fw .. (i think so) (there are some .js routines).

So the solution is maybe to make that to the body element dynamic applied styles / classes (more) ios compatible - so that the explained snap-down will not occur...

This issue is really a big problem for me, because all kind of Dialogs (Login, Signup, Edit, etc.) are not usable for any iphone / ipad User.

Affected: All Apple i-devices with safari, IOS: 11, 12, 13, IpadOS: 13

It would be really great to get here a solution. Many thanks to the Team.

pdanpdan commented 4 years ago

There is not much we can do on the framework side. For iOS you have to set some CSS for the dialog, but this CSS is very specific for each use-case. The basic idea is this:

detect if the dialog has a field that requires keyboard input focused
if it has then add a class on the dialog and style it so that it covers at most 50vh and is aligned on the top of the screen

You can check an example here: https://codesandbox.io/s/codesandbox-app-44xoy

ibrainventures commented 4 years ago

Hi Dan,

its a little funny to read this bloody workaround which i posted myself a week ago inside the discord components channel: (wednesday , 12:23)

... make those input fields nearly above the virt.keyboard and made a resize of the dialog at the focus event (on the input) .. but with landscape ....

but i also wrote, that to handle all use-cases is nearly impossible .. :-(

But ... much more important is, that this dialog on ios has worked until version bump 1.1.0 without any problems.

To get the impression : Please check my sandbox - same origin code - only with 1.0.5:

https://o54fx.sse.codesandbox.io/

*** - they primary occurs after the version change from 1.0.5 to 1.1.0 .. May all depends on this prevent-scroll.js routines ?

There are some more issues since , like the hopping of the the complete layout if a drawer (overlay!), dialog, etc. is invoked or those nasty - infinity-load fireing when a dialog is opened ..

Please understand this "manifestation" of this problem-situation as my constructiv critic, as i realized, that i am locking out 1 Billion ios-device Users with a non working dialog scheme since this issues (no scrolling / no entry possible) .. (and its called Dialog and not Notify :-) ) ...

rstoenescu commented 4 years ago

Fix will be available in "quasar" v1.2.5 shortly (today).

ibrainventures commented 4 years ago

@rstoenescu @pdanpdan

90.9 percent happy ...

Wow .. what a big step, first time a Dialog without backscrolling and also the Input-Fields are working. (i am sure, there are not many vue, angular, ... frameworks outside who are solving this out of the box ... !! :-) )

And I am also sure, that i heard here in Frankfurt some romanian curses and banes *%$%$$$ yesterday against some webkit-developer in CA :-) ..

To understand my little tear (the left 9.1 percent for full-happy) that the layout is jumping down when a QDialog, QDrawer, Bottom-Sheet etc. is invoked.

(which happens only since 1.1.0 .. -> also "a side effect" of the non-scrolling option ?)

With jumping down i mean:

Ipad -> Safari -> have some Tabs (normal state for a ipad user, that there are some tabs open)

-> Portrait Mode (!) -> go to ; https://quasar.dev/start/pick-quasar-flavour -> scroll a little down, so the tab bar is small-size

grafik

Open a Drawer, Dialog, Bottom Sheet, .. then the tab bar get maximized and the complete layout jumps around 50px down:

grafik

(btw: if you start in landsacpe mode -> go to the quasar docs, the drawer is not in overlay, so no jumping .. also if you turn into portrait mode)

To prevent this jumping i can add inside app.sass:

.q-body--prevent-scroll position: -webkit-sticky !important

but i know, that i am destroying then the "prevent scroll additions, which prevent the background scrolling.

long story short

It would be great, if you can open me a way for easy, programmatic adding this css-rule if i have e.g. a dialog, drawer, bottom sheet, where i can ignore that background scrolling issue, but have the workflow like a normal "Dialog (also with persistent etc.) / Drawer / Bottom Sheet .. without layout jumping (like V 1.0.5)

ibrainventures commented 4 years ago

add; or a programmtic way to prevent adding the css rule which effects the tabbars by the prevent-scroll.js

ibrainventures commented 4 years ago

if possible, that behavior-boolean-prop can called with-ios-issue :-)

ibrainventures commented 4 years ago

@pdanpdan @rstoenescu

sorry .. if a may are paranoid .. but .. there is a waiting pr with going by "dialog resize" ...

this will not work as we got it actually ... on iphone / eg. landscape etc. this

looks like this - and once again the scrolling is prevent (i used pdans sandbox):

grafik

Big questionmark ...

pdanpdan commented 4 years ago

I don't know what you tested, as in your screenshot there is a v1.2.4. Please describe the problem, using as much information as you can and as little .. but .., ... as you can. Maybe you know what you mean, but that does not mean we can gues it.

ibrainventures commented 4 years ago

The screenshot / behavior is when using your sandbox

https://codesandbox.io/s/codesandbox-app-44xoy

from monday. My fear is, that the upcoming pr is more-or-less the routines like in your sandbox and reverting that acutal 1.2.5 handling, where the screen is not locked during the virtual.keyboard display.

pdanpdan commented 4 years ago

That was a 2 minutes play on your codepen. You can always test bleeding edge by running

https://codesandbox.io/s/107352q2nj https://107352q2nj.sse.codesandbox.io/

Just be patient while it starts.

ibrainventures commented 4 years ago

test on iphone 6 plus , 420 px height (others have 380px / 414px)

grafik

keyboard over input-field, scrolling is blocked. no input possible.

ibrainventures commented 4 years ago

my opinion: (as shoort as possible):

if prevent-scroll is activated - then -> upflow for elements is blocked (but this wants ios safari on mobile devices)

pdanpdan commented 4 years ago

You can test with a new version. But as far as I'm concerned, from this try further you can try and complain to Apple :)

ibrainventures commented 4 years ago

good morning dan,

i hope it is allowed to give a construcive feedback:

Great Code .. great workarounds ..

I got stucked when opening the ios bottom and close the virt.keyboard by "ready" button (its not the submit / enter button-function) - its only closing the keyboard.

The input field (inside the dialog) is scrolling downsize the lower browser viewport. So i cant get the focus for the input element and also as persistent / scrolllocked i cant go further inside the app without reloading ..

why the closing keyboard scroll is below .. thats may a ios "feature" but depends on the addressbar slide ins (maybe).

if iam recap right there was a (true) param for the scrollintoviewif... which centers the input field inside the viewable area .. not sure if this help ... (there were also some param for smooth for the normal - scrollintoview method)

(small typo : serach instead of search ..)

but ... great solution ...

pdanpdan commented 4 years ago

This looks like a promising version: https://107352q2nj.sse.codesandbox.io/ But I could only test it on an iPhone 11. If anybody can test it on other devices, and especially on iPads it would be great.

ibrainventures commented 4 years ago

ios bottom works on both now !! 👍

stucked on ipad & iphone:

SLIDERS:

"Select multiple- Use input" -> typing some letters, the lower part with default choices closes .. then there is no more reaction to close the smaller-sized inputfield .. (seems that the former filled area gets no touch - reactivity back)

(out of reality-test: IOS TEST 2 ) .. sometimes / often no upscroll possible (also if no input-focus activated ..)

IpadOS13 - (default (out of the box safari setup : Render as Desktop side): (this (should) prevent (or make it better) background scrollign by default):

Only tested : "IOS TOP" -> no scrolling, but backdrop and scrolllock happens, cant see / reach the top Dialog ... :-(

https://developer.apple.com/documentation/safari_release_notes/safari_13_release_notes#3314682

iam still overwhelmed how much you invest to make a perfect non-background scrolling dialog.

I am no fan of capturing the userinputdevices (e.g. scrollwheels, etc.) and make e.g. some smoother scrollings (this was 5yrs ago by some fw fancy for make smoother parallax scrolls etc.) .. and "destroying" the global interrupt / usersettings / system design which was native planned or happens through the os. ( if i come on a website where my mouse got slowmotioned by js .. i am always critical .. ) ..

May there is a golden-cut with a behaviour prop "with background scrolling prevent" .. and then the quasar app developer can choose how compatibel / userfriendly his design is. The mayor part (a dialog with a working input field is now 1.2.5 possible .. which had his problems since 1.1.0).

You asked .. i tested .. may other got other experiences .. no demand by me. (going to bed now ..)

ibrainventures commented 4 years ago

Hi Dan, i cant attach a picture with my big smile :-) .. Not enough width-pixel on git-upload possible :-)

Great compromise .. !!

Tested on Iphone 6+ ios 12.4x Ipad - ipados13 with and without "render as desktop" option.

Never came into situation where i am stucked .. so i always can re-arange the positions.

Two (smallest) things .. only for perfectionistcal sugaring .. :

Iphone:
IOS TEST 2 : select first / highest input field : -> on focus its jumps nearly behind the addressbar.

Ipad (nearly every time) / Iphone (sometimes): IOS TOP : Without entry / empty input field -> scroll a little down -> after click on the IOS TOP Button it jumps out of viewport. (if the field is not empty .... it works mostly perfect) ..

👍 👍

ibrainventures commented 4 years ago

Good Morning Dan,

hope its allowed to write a little testrun-feedback from this morning:

IOS TOP - IOS BOTTOM - IOS NORMAL:

With the 977b080 it seems there is a little timing-issue with the Component Display.

Ipad Landscape primary tested, (but also happens on the iphone) the component is not displayed / final rendered (but no so often . may because the iphone 6plus is not the fastest smartphone ..)

Only blinking cursor, and need touch to reactivate / display the Dialog Component. Seems that the sliding-in-Keyboard is occuring some calculation / displaytiming issue.

May other testers has this effect also?

(the IOS TOP (first input field issue) on Iphone is now perfect 👍 )

pdanpdan commented 4 years ago

Thank you for the feedback. I'll need a new test tomorrow morning - I have to find some magic numbers :(

ibrainventures commented 4 years ago

sometimes magic mushrooms can help ;-) .. hope the current and future quasarians can appreciate all your work for this ...

will wait for a next "go, for testing".

ibrainventures commented 4 years ago

Dear @pdanpdan,

please .. if you have 5 minutes, please read my following lines and if there is need for clearing out, i am always reachable by discord.

Quasar is great, is perfect, is the "eierlegendewollmilchsau" of the frameworks. The Team is great, the effort of Raz is unbeliveable and the future is bright.

The only critical thing is the backscroll handling and ui-distortion on ios.

If you develop a actuall webapp with qdialogs and qdrawers and you give it to the ios world, the experience is mixed. The displacement of elements on Drawer opening and narrowing the viewable space is no native-like feeling and there is also a bad effect e.g. on the infinite scroll if it is in the background screen. This infinite Scroll fires unlimited and this makes other trouble. (i can stop it by handling the frontend event)

My first "ios issue" with angular and mobile is over 5 years ago.

https://github.com/mcasimir/mobile-angular-ui/issues/139

Since them, i analyzed many, many ... solutions so i can say, i am experienced backscroll / displacement issue person.

A really perfect solution, which has no Displacement effect, no scroll up block effect on ios (also IpadOs with/without desktop request etc.) i found on:

https://github.com/FL3NKEY/scroll-lock

Landscape, Portrait, Shaking, switch-on/off Testing .. all was solved without any issue.

Live demo: https://fl3nkey.github.io/scroll-lock/demos/index.html

I am no good programmer to implement or test this with the quasar fw. My coding looks like a tnt.bomb inside a italian-pasta-factory.

But may you can take a look and may find the "missing-element" for getting the ios drawer / dialog working with:

perfect background scroll prevent
no displacement when dialog / drawer / loading-circle etc. is shown
no ios addressbar / navbar forcing when dialog / drawer / etc. is shown
no background infinite fireing

Thank you very much for taking the time J.

ibrainventures commented 4 years ago

addendum: the addressbar / navabar occuring happens to the .q-body--prevent-scroll, .q-body--fullscreen-mixin css applies (position fixed).

and the displacement by the css apply .q-body--force-scrollbar .q-body--loading

pdanpdan commented 4 years ago

Reopening this for tracking further experimentation.

ibrainventures commented 4 years ago

Good Morning @pdanpdan

i took the time for some experiments with the js library from my former post.

Steps:

Integrated:

https://github.com/FL3NKEY/scroll-lock

made a Boot file and made inside app.vue mounted hook:

this.$scrollLock.addScrollableSelector('.q-card')
this.$scrollLock.setFillGapMethod('none')

(didnt find the right gapping method inside the fw with our centered drawer layout .. so better to do no gapping by default)

Now, the important part ..

position: fixed for iOS is the troublemaker. It is forcing the adressbar / navbars and may some other trouble (may the infinite fireing .. )

So .. to get here rid of that effect:

.q-body--prevent-scroll, .q-body--fullscreen-mixin
  position: -webkit-sticky !important

And If i am opening now a dialog with fixed / scroll-locked background with:

    <q-dialog
      no-focus
      v-model="dialogTrigger"
      @before-show="$scrollLock.disablePageScroll()"
      @before-hide="$scrollLock.enablePageScroll()"
      transition-show="slide-up"
      transition-hide="slide-down"
      position="bottom"
    >

The Body / Background is absolute hard-hammered fixed .. no scrolling .. no wiggling .. Also all elements from the Dialog ( also deeper nested ) are scrolling fine. Never stucked in a bad end situation. Also the positining is working fine.

It is a much more fluent working .. If the pages are high enough you never get a deplacement or invoking of any adress / navbars ..

Eg. a "bottom sheet style" dialog fly-in .. Very fancy on ios these days. If this needs a scrolllocked background it should not have stucked (edit: stapled) over (edit: invoked ios-) navbars eg (iphone) or deplace the whole screen (ipad)

With the above "webkit sticky" overrule it looks now like this.

quasar-sl-1

(btw. the upspaced navbar is no error , i am doing this to prevent the "unsafe ios footer part on iphones.." which also invokes the navbars ...)

May, if you have time you can take a look on this library and the way without the "position fixed" for scrolllocked qdialogs, qdrawers, .. on ios plattforms

Many thanks.

Tested on:

Chrome, Firefox, MS Edge, Ipad, Iphone Ios (12.x - 13.x), Android Landscape, Portrait, Touch , NoTouch etc. etc.

pdanpdan commented 4 years ago

Can you please try to put an input on the bottom of the dialog and check if the keyboard covers it? I'll try to do some tests myself next week.

Thank you.

ibrainventures commented 4 years ago

Tested on Ios 12.4x Iphone, portrait and landscape:

quasar-sl-2

Always slides up, and is still scrollable ..

Btw: iPadOs -> Render as desktop, is breaking the max-height of this nice height-limited bottom sheet (as the viewport is overruled) -> only a visual breakup - but a bad side-effect

Update: only if the bottom-sheet content is very long ... (> 800 px ...)

ibrainventures commented 4 years ago

And last but not least:

Those Landscape Screenshots are taken from a normal quasar webpage (not Homescreen attached started, not PWA, ) on the iphone.

It is 100 % viewport filled, without any Browser Nav, Tabs, Adressbars. .. And if a fullscreen Dialog is invoked (no App fullscreen is need (and not supported by iphone!) .. it is a great ui feeling (the scroll down inside the fullscreen dialog prevents any navbars also ..)

-> thats a really really perfect Native near feeling ..

Quasar at its best :-) !

ibrainventures commented 4 years ago

Hi @pdanpdan you give me / us a sign if you need someone for testing?

I tried to analyse the changes, but i am still convinced that the right way for scrollocked / scroll-prevented dialog / modal / loader-animation / drawer etc. is:

step 1 : body : overflow: hidden step 2 : fill-the-gap (if the scrollbar-takeaway left some space / layout changes) step 3 : scrolllock routine with giving the dialog and / or nested elements a scroll / overflow

Tested with the above npm package and thats working really nicely. There are no special ios-keyboard detections or edge-cases-ifs necessary, all (quasar) elements are working fine and get perfect reachable / inputtable on all ios/android/touch-devices.

actually the workflow is:

step 1: position : fixed step 2 : showing a scrollbar to fill the gap step 3 : handling for scrolllock elements

as written in our discuss above, this flow makes some ui-problems:

the "position fixed" is occuring on ios devices a ui unfine deposition / addressbar, navbar presenting
the overflow scrollbar is not really nice

A really good article about this i found on: https://medium.com/react-camp/how-to-fight-the-body-scroll-2b00267b37ac

and if i look on some mayor websites , e.g. https://www.instagram.com/topromaniaphoto/?hl=de

and you click on the image where a modal is forced, there also this first workflow. (okay, filling the gap is forgotten :-) )

pdanpdan commented 4 years ago

@ibrainventures I just have a new baked test version :) Add "quasar": "https://github.com/pdanpdan/quasar#quasar-v1.5.9-test.1-gitpkg", in your application's package.json under "dependencies" + yarn.

I would like impressions on how it works (Safari/Chrome, iOS/iPad, cordova would be a bonus).

ibrainventures commented 4 years ago

i tested .. thank you very much for your work. Sorry i cant give a codepen or something else, to show my test.

I comment all my npm-scroll-lock out and with that 1.5.9-test.1 all problems are back.

Fixed background on ios with navbar/adressbar showing (forced by the body fixed)
the keyboard is overflowing a q-input on a full-height-dialog, where the q-input is in the bottom part. -> no upscroll possible , input reachable.

tested on ios 12.4.4 , iphone.

If time, please look on my last comment, After now x-hundred hours of dialog issues (also on angular , react apps) i am absolutely convinced about the "other" way.

pdanpdan commented 4 years ago

Ah, the fixes are for iOS 13+. I'll check the overflow, but from what i can remember it's not working very good either.

ibrainventures commented 4 years ago

now tested on IpadOs 13, the upflow is working,

Adressbar etc, are presented (deposition, ui break)
the scrolling list inside my fullheight dialog is after a second keyboard presenting not scrolling anymore...

ibrainventures commented 4 years ago

i will bet my left kidney, that if we get rid of the "position: fixed" and going by "overflow: hidden" all (ios 10+) overflow problems are away :-)

ibrainventures commented 4 years ago

all-in :-) .. i would also bet my left liver for the overflow, after checking how discord, twitter and instagram handling a modal / dialog / popup:

Discord:

grafik

Instagram:

grafik

Twitter:

grafik

pdanpdan commented 4 years ago

It doesn't matter how some applications implement it - they are not generic frameworks.

rstoenescu commented 4 years ago

Reviewed https://github.com/quasarframework/quasar/pull/5377, tested on Safari browser, Capacitor and Cordova (Cordova with ionic webview). Noticeable improvement.

Will be available in "quasar" v1.5.10.

ibrainventures commented 4 years ago

thanks for your upgrade and work on this issue.

difficult to recap about the changes between the (direct from pdan npm-ed) yesterday testpackage and the now upgraded changes. Yesterday we got the old problem (not scrolling up / hidden input fields on ios < 13) . For the overflow-hidden usage style i will keep my hopes for q-2.0 :-) .. May i can make a demonstration pr in 2020...

The actuall pr has some window.scrollTo 0,0 routines:

grafik

I am a little unsure, is that forced scrollup not breaking the user-interface. For example, we are working with keep-alived / key-ed dialogs inside chat and messaging and its nice to hold those positions.

rstoenescu commented 4 years ago

Ah, lol. Pushed fix for this an hour ago :)) Thanks for reviewing also <3 @ibrainventures

ibrainventures commented 4 years ago

sorry @rstoenescu for going again into this code.

ios 13 is delivering always true for the window.visualViewport !== void 0, (also if not inside a viewport-zoomed-situation). So the forced window.scrollTo 0,0
of , i.e. a document / list / behind the dialog will allways at opening a dialog on all ios13 devices forced?

pdanpdan commented 4 years ago

It's moving it to the place where the dialog shows. In theory it should only move it if the dialog is a bottom one.

ibrainventures commented 4 years ago

On the iphone the dialog is mostly display-filling, but on a i.e. ipad the user has a much huger display area, and a overlayed-dialog is mostly a much smaller visual element. So there will always a document re-arange behind?

pdanpdan commented 4 years ago

As I said, in theory only if it's a bottom one and the keyboard covers the bottom.

ibrainventures commented 4 years ago

hi @pdanpdan @rstoenescu

to leave the theory i build based on the quasar-dev from this morning a temp-1.5.10 release and tested it on the ios 12 and ios 13.

On our setup i got some unexpected behaviours - like white screen-time for 1+ sec. with a longer list in the background at dialog opening (a center positionated dialog - iphone ios12) and on the ipad ios 13 the input fields where sometimes overflowed by the keyboard. (mainly bottom positionated dialogs). (also some depositioning of the background lists and the iphone with ios12 goes the temperature strangly hot ..)

To make it for all participants easier i will go with a patched dialog / prevent scroll routine so there is no more "annoying" person (me) on blocking your know-how and ressources.

Thanks again for all your effort and time for making this great baby possible.

overflow

quasarframework / quasar

QDialog [ios] [ipados] Keyboard is overflowing inputfields on Dialogs #5351