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

Modal input-field Cursor positioning Bug on mobile #24835

Closed
rranke opened this Issue Nov 20, 2017 · 21 comments

Comments

Projects
None yet
@rranke

rranke commented Nov 20, 2017

The problem is, that when entering some text into an input-field in a opened-modal, the text-cursor does not stay in field but shifts down under the input-field :(

Tested on iPhone 5s, iOS11 at
https://getbootstrap.com/docs/4.0/components/modal/#varying-modal-content

@Johann-S Johann-S added css v4 labels Nov 20, 2017

@rranke

This comment has been minimized.

rranke commented Nov 21, 2017

img_0356

@tmorehouse

This comment has been minimized.

Contributor

tmorehouse commented Nov 21, 2017

The cursor appears to be offset by the amount of scroll that has happened on the modal (as it is pushed up by the virtual keyboard)

@andreolaya

This comment has been minimized.

andreolaya commented Nov 24, 2017

There is currently some suggestion to solve this problem?

@tmorehouse

This comment has been minimized.

Contributor

tmorehouse commented Nov 24, 2017

One suggestion (based on these stack overflow answers):

Is to add style position: fixed to the document body while modal is opened.

body.modal-open {
  position: fixed;
}
@mdo

This comment has been minimized.

Member

mdo commented Nov 24, 2017

Duplicate of #24352.

@keyhangholami

This comment has been minimized.

keyhangholami commented Feb 21, 2018

I had the same issue. According to this link:
https://www.igorkromin.net/index.php/2016/05/20/mobile-safari-scrolling-problem-with-an-input-field-inside-a-fixed-div/

By putting the following rules in CSS, the problem has been resolved.
html,body{ -webkit-overflow-scrolling : touch !important; overflow: auto !important; height: 100% !important; }

@kimek

This comment has been minimized.

kimek commented Feb 28, 2018

@keyhangholami this will scroll site to top if you open modal ex. in the footer. Solution for a now is to use JS and scroll back however you will see that page posiiton is changing .

@horaceleung

This comment has been minimized.

horaceleung commented Mar 2, 2018

this will scroll site to top if you open modal ex. in the footer. Solution for a now is to use JS and scroll back however you will see that page posiiton is changing .

@kimek can you elaborate on this? How can it be done?

@edsongti

This comment has been minimized.

edsongti commented Mar 5, 2018

Try to add this meta tag:

meta name="viewport" content="user-scalable=no,initial-scale=1,maximum-scale=1"

@kimek

This comment has been minimized.

kimek commented Mar 5, 2018

Best solution is use different style for modal (no opacity) on IOS 11 onwards. Best answers is here https://stackoverflow.com/questions/46339063/ios-11-safari-bootstrap-modal-text-area-outside-of-cursor @horaceleung
Position fixed + form elements are bad idea on IPhones.
Position fixed itself is fine.
More about updated IOS11 version here https://hackernoon.com/how-to-fix-the-ios-11-input-element-in-fixed-modals-bug-aaf66c7ba3f8

My idea is to fix this issue is to use web components instead of form elements.. maybe IOS11 won't 'fixed' that.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Mar 5, 2018

meta name="viewport" content="user-scalable=no,initial-scale=1,maximum-scale=1"

you can save yourself the user-scalable=no and maximum-scale=1, because iOS now (quite rightly) ignores them (as they prevent users from being able to zoom when they may need to)

@kimek

This comment has been minimized.

kimek commented Mar 5, 2018

@patrickhlauke IOS not ignoring "user-scalable=no and maximum-scale=1", it's adding on top of it zoom option which is not same as ignoring. Page with and without "user-scalable=no and maximum-scale=1" will zoom differently.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Mar 5, 2018

@kimek do you have an example of this in action? initial-scale does have an effect, but my understanding was indeed that the other two directives were ignored (see https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/)

@kimek

This comment has been minimized.

kimek commented Mar 5, 2018

@patrickhlauke from my dev team experience ex. If you add " content="user-scalable=no,initial-scale=1,maximum-scale=1" it will stop auto zooming on input focus, zooming the page with one/two taps are 'less' possible. Still you can zoom however in a slightly harder. I will check that if it's true again and leave comment about that does this effect or not.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Mar 5, 2018

@kimek check if just content="initial-scale=1" has the same effect (removing the ignored bits)

@kimek

This comment has been minimized.

kimek commented Mar 5, 2018

I know 100% that only "maximum-scale=1.0, user-scalable=no " was added as I see diff now and that change iphone behave @patrickhlauke

@Eurymachus

This comment has been minimized.

Eurymachus commented Mar 7, 2018

Hi kimek, Your solution 'worked' however it broke all other scrolling on the site in terms of my 'fullpage' implementation.

user-scalable=no, initial-scale=1, maximum-scale=1 made no difference to the carat positioning bug.

Are there any other suggestions? Otherwise I'm going to have to go with a static form page.

Thanks all.

@sarathlalem

This comment has been minimized.

sarathlalem commented Mar 10, 2018

I have faced the same problem when I was working for my website. Hence I started to fetch details from all the websites possibly arranged from the big dad “Google”. However, I could not find a proper solution to fix the issue. So with disappointment I turned to my own self and started to work on probability and solutions. But dramatically, I found a permanent solution to the addressed issue. So first of all, kudos to myself and my trial and error capabilities.

I share the same solution for all of your to refer and kindly let me know in my email if this helped.

Solution:

  1. Identify the parent class and remove position: fixed to absolute.
  2. Use the below code:

$('.getStartButton-login').on('click', function (){
$('body').addClass('get_hide')
})
$(document).on('click', '.log_form__close', function (){
$('body').removeClass('get_hide')
})

Thank you so much and find me in Facebook : sarath lal.em

Good Luck!!!

@mikermcneil

This comment has been minimized.

mikermcneil commented Mar 14, 2018

For us, saving window scroll position then scrolling it to the top, display:none-ing other content, and applying the following to the modal worked:

$(this.$el).css({
  'overflow-y': 'auto!important',
  'position': 'absolute',
  'left': '0',
  'top': '0',
});

(and of course, you have to undo all that when the modal closes)

image

image

These adjustments will be included by default in the modal Vue component provided by default in the "Web app" template in Sails v1.0

@coliff

This comment has been minimized.

Contributor

coliff commented Mar 23, 2018

FYI; This webkit bug is fixed in iOS 11.3 which should be released to public very soon. I've tested this myself (public beta) and confirmed by others.
REF: https://bugs.webkit.org/show_bug.cgi?id=176896

@aaroniker

This comment has been minimized.

aaroniker commented Mar 29, 2018

finally ios 11.3 is out and this issue is fixed! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment