i have an input field, in a browser where the content is not shown entirely,Like below image.
The webpage is for tablets and phones. If I want to make a correction before Submit, on the first touch the caret is positioned where the touch happens but if I want to correct my position on second touch the caret is positioned at the end of the text not where the touch happens, I have this strange behavior only on iOS 8. It's annoying on small tablets since the content usually is longer than the input field.
Is there a way to position the caret where the touch happens?
Related
The question
When window.onresize event is fired, the bottom menu should become hidden if window.innerHeight is smaller than it was at window.onload.
Will this behave consistently across mobile browsers and operational systems?
Rationale
This is the solution I found to deal with the fact that mobile keyboards resize the viewport when they come out. If the bottom menu is not hidden when the keyboard comes into view, it will get stacked upon the keyboard.
This solution works as expected on Chrome v80 running on Android 7.1.
I wonder, however, if the below cases are common, since they would brake the mechanism:
Browsers that won't trigger the resize event when the keyboard comes in and/or leaves
Systems/browsers that keep the keyboard visible while navigating to a new page, therefore making the initial window.innerHeight value different from the actual viewport size without keyboard
Important: Doing the toggling through Input focus/blur events is out of question. I've found that on my Android phone, when the System's go-back button is pressed, the keyboard hides, but the input does not lose focus, therefore the bottom menu stays hidden.
This issue is particularly difficult to explain...
In Mobile Safari (and not in Chrome on Android), when an input is focused and the view adjusts to put the input in the center of the screen, I've noticed that sometimes the elements that were previously there still have their touch events in place.
See the video below, in which I click slightly above the "apply" button, which ends up clicking on the "total price" header, which causes the dropdown to collapse. Obviously, that ghost touch event should not be there.
Basically, when I focus on the input, the screen moves as expected, but the touch events for the elements that were there before don;t move with them. If I touch in the same place that an element used to be, it triggers that event.
https://youtu.be/5tFNfnd5RO4
I know for sure that the event being triggered here is the one for the "total price" bar, because if I click slightly below it to the right, I can trigger the event for the "change" button.
Note that this doesn't happen consistently. I cannot replicate this 100% of the time, but I was able to capture it on video.
This is a known bug in iOS and they say they're going to fix it in the 11.3 release.
https://www.apple.com/newsroom/2018/01/apple-previews-ios-11-3/
I try to find some workarounds for mobile safari bug:
For example I have a clear html page with
Viewport settings width=device-width, noscalable
Body with position:fixed
Two HTMLInputs created by js and placed to center of screen
All works fine on ever devices but on Iphones 6 plus and 7 plus we have a great problem:
If I've focus input and then hide keyboard, all window positioning become diverged from rendered position. Input could be only focused if I've click ~100px higher of it visible position. Moreover, each additional elements on page (even canvas with webgl content) also will get wrong coordinates on each tap/touchstart and so on.
I've connect iphone for debug, and I can see that browser thinks that input placed not where it rendered. Also i can vertically scroll page with finger, and real rendered inputs will stay in place, but area from browser will moves up and down right up to his rendered position.
Bug could be reproduced only if few tabs opened in browser in landscape orientation (i'll highlight tabs red on screenshot).
Can't reproduced on iphones5-6, because there is no tabs, but also can't be reproduced on ipad, which has the same tabs.
Example is here: http://baker-feather-16713.bitballoon.com/
Problem is the fact that safari allow user to scroll page to fullscreen ever if you set html/body width and height to 100%. So, when keyboard showed content scrolls up despite that body has position "fixed" and it rendered with bug when keyboard becomes hidden.
Solution is very simple: just need to do scrollTo(0, 0) when keyboard hidden, e.g.:
document.addEventListener('focusout', function(e) { window.scrollTo(0, 0) });
Mouse peripheral causes the styling of the scrollbar to change. How do I prevent this from happening or change the background color of the scrollbar box so that it matches the rest of my site?
This is the desired effect when I have scrollable content:
Without Mouse Plugged In
This is the undesired effect when I have scrollable content with a mouse plugged in:
With Mouse Plugged In
Here is a link to code that models the scrollable portion in question:
http://www.w3schools.com/cssref/tryit.asp?filename=trycss_overflow
I'm experiencing this issue my Macbook Pro (I haven't done any testing on a Windows device.) I'm looking for a solution that works in Safari, Firefox and Chrome.
In my webpage I have a text input field which gets covered by the keyboard in Windows 8.1 tablet.
I want the tablet to 'push up' the web page content (as it works on the iPad).
So:
Is it possible to make the keyboard NOT covering my input field?
And can I detect if a virtual keyboard is active with javascript?
You could get the relative position of the text field in comparison to the screen resolution and if the field lays on the 2nd vertical half (i.e. the space that covers the keyboard after appearing), scroll down the webpage for a fixed amount of pixels.
If you use jQuery, you could use the jquery.scrollTo plugin to scroll to the field with a vertical negative offset, so the field is always visible.
Plugin site: https://github.com/flesler/jquery.scrollTo
Hope this helps!
I have no Windows tablet to be sure of how the OS manages the keyboard pop-up, but this method has worked for me on Android and iOS.