Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ibrainventures opened this issue Oct 19, 2019 · 23 comments
Assignees
Labels
bug

Comments

@ibrainventures
Copy link

@ibrainventures ibrainventures commented Oct 19, 2019

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.

@ibrainventures ibrainventures added the bug label Oct 19, 2019
@pdanpdan

This comment has been minimized.

Copy link
Collaborator

@pdanpdan pdanpdan commented Oct 21, 2019

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

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 21, 2019

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

This comment has been minimized.

Copy link
Member

@rstoenescu rstoenescu commented Oct 22, 2019

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

@ibrainventures

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

@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)

pdanpdan added a commit to pdanpdan/quasar that referenced this issue Oct 23, 2019
pdanpdan added a commit to pdanpdan/quasar that referenced this issue Oct 23, 2019
@ibrainventures

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

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

@ibrainventures

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

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

@ibrainventures

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

@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 added a commit to pdanpdan/quasar that referenced this issue Oct 23, 2019
@pdanpdan

This comment has been minimized.

Copy link
Collaborator

@pdanpdan pdanpdan commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Collaborator

@pdanpdan pdanpdan commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

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

grafik

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

@ibrainventures

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 23, 2019

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 added a commit to pdanpdan/quasar that referenced this issue Oct 23, 2019
pdanpdan added a commit to pdanpdan/quasar that referenced this issue Oct 23, 2019
@pdanpdan

This comment has been minimized.

Copy link
Collaborator

@pdanpdan pdanpdan commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 28, 2019

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

This comment has been minimized.

Copy link
Collaborator

@pdanpdan pdanpdan commented Oct 28, 2019

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

@ibrainventures

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Oct 28, 2019

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

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Nov 7, 2019

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

This comment has been minimized.

Copy link
Author

@ibrainventures ibrainventures commented Nov 7, 2019

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

This comment has been minimized.

Copy link
Collaborator

@pdanpdan pdanpdan commented Nov 8, 2019

Reopening this for tracking further experimentation.

@pdanpdan pdanpdan reopened this Nov 8, 2019
@pdanpdan pdanpdan self-assigned this Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.