when I try to make a Next/React project in which I have an invisible input.
Almost the whole page is my label for that input.
when I use my mobile browser and the soft keyboard appears it forces the page to be scrollable which interferes whit my design
I want to either adjust the size of the page so that the
height(page)+height(keyboard)=height(screen)
or
make the whole page unscrollable.
I don't know why but it is scrollable in Brave browser but not in Opera GX browser
I want it like it is on Opera GX.
I tried setting the overflow of html, body & #__next to "hidden"
but that didn't work.
You can see what I am talking about on my website: phew
The problem: I'm working hard to implement a responsive UI in my app. But the keyboard IME on Android squishes my entire page layout into a frame that's about 96 pixels high when in landscape orientation. Typically this means that the input control being edited is not visible in the space above the IME. And one cannot edit a value that's not visible in Chromium. I'm assuming iOS has the same problem.
Setting a minimum height for the page helps. But the Chromium scroll-into-view implementation is not robust enough to keep up with some of the more complex page rewrites that are triggered by a change in window size in my app.
Ideally, I'd like to run the keyboard IME in "extract" mode, where the page is entirely hidden, and only the value being edited is displayed in the space above the IME. But as far as I can tell, there's no way to do that, even in Android native apps. Chromium never runs the keyboard IME in "extract" mode, even in landscape orientation.
The solution I'm current implementing: simulate "extract" IME mode by perform editing of values in a full-screen dialog that contains nothing but a single dedicated <input>.
The question is: how should I detect when to use this solution. it's easy enough to check the browser's navigator.userAgent. The Mozilla foundation recommends checking for /Mobi|Android/ (although I've seen solutions that have 40 or 50 patterns). But I'm wondering whether there's a feature-driven way to check for this instead -- something more along the lines of if ("geolocation" in navigator) ....
But as far as I can tell, there are no features related to whether and how a keyboard IME will change the layout of a page. If there are, I'd like to know. The "feature" I'm looking for is something along the lines of "Will this browser lay out my entire page in a frame that's 96 pixels high (in landscape) whenever an input control gets focus". But "does this browser uses a keyboard IME" would be satisfactory.
Any ideas appreciated.
I have a problem that I can not solve, in Android devices when you put text in the input,
so due to the appearance of the keyboard,
all the elements are popped up - I attached pictures.
How can this problem be solved?
How can I turn off the default css settings of browsers in Android? Because in iOS it works great
Thank you :)
Popping up keyboard is resizing Activity by default, thus it has less space so web content also, and it looks like in your case web content still trying to "fill whole space" trying to align to bottom, center etc. - that depends of params set in CSS
Consider preventing this Activity resizing by android:windowSoftInputMode="adjustNothing" line in manifest
<activity
android:name="your.package.activity.WebActivity"
android:windowSoftInputMode="adjustNothing"
... rest of params
with this line your Activity won't be resized, instead of that keyboard will show up "above" your View (so will cover half of content). you can also try with adjustPan value, for sure not adjustResize. some doc in HERE
I'm aware of the general strategies for hiding the address bar, e.g. encouraging installation as home screen app and/or sometimes scrollTo hacks. In my case, however I am fine with the default behaviors. As the user navigates my app, the browser tends to eventually hide the scroll bar and that's fine.
My problem is, users need to do a lot of text editing in my app. When this happens, especially in landscape mode, the soft keyboard can take up tons of the visible screen but to make matters worse, the bar tends to re-appear! On top of over half the screen getting taken up by the keyboard itself, an additional 1/5th or so gets suddenly eaten back up by the address/tab interface even if it had gone away.
So I'm left with a tiny strip that the user can see, for no apparent reason.
I suspect this is a long shot, but is there any way to discourage these tabs from re-appearing? To be clear, the user is not trying to edit the URL, but has simply focused in an <input>/<textarea> to edit that.
I have a full-screen game in HTML+JavaScript, which uses the arrow keys as primary controls. This cannot be used on keyboardless Android devices (I haven't tested on iOS), and even if the soft keyboard had arrow keys it would take up unnecessary space. Therefore, I have added onscreen control buttons. However, the buttons are unnecessary (and absurdly large) on desktop browsers, so I would like them to not pop up unless they are needed.
What heuristics can I use to decide whether they are needed — that is, whether it is impossible or awkward for the user to input arrow-key events — other than recognizing specific User-Agents (which is straightforward, but not future-proof)?
I will of course allow the user to hide/show the buttons; I am looking for useful heuristics for choosing the default setting.
No need for any user-agent sniffing, config options or any kind of guessing. Just do this:
Have a title screen which says "press to continue".
On click or key press, hide touch controls and start game.
On touch, show touch controls and start game.
You never even needed to mention the option to the user and you auto-detected their preferred control perfectly.
Use feature detection with Modernizr: http://www.modernizr.com/docs/#touch
While this is not a reliable way to check if the user has a keyboard it is definitely reliable to see if the browser is capable of touch.
Instead of trying to guess, make it a config option for the user to choose.
If you have only arrows (left/right/up/down) you might consider adding touch-events inside the game field? This would not take up space obviously as it is layered on top of the game, so it could be 'always on'.
A computer user would not even know it is there, though he/she could use them to play your game with a mouse I guess.
The touch-device user on the other hand can much more easily use the "areas" (mid top, mid left, mid bottom and mid right for instance) because of .. well.. touching instead of using a mouse.
This might need some explaining, as you probably would not want the points to be visible to the user, but it feels like a valid option.
Even if you have 4 buttons and a 'fire', you could do this, for instance by adding a 'middle' section.
look for touch specific events such as touchstart or gesturestart and show the onscreen controls if detected.
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html
I am not sure if the system-info api has been implemented by any browsers:
http://www.w3.org/TR/system-info-api/
rather than displaying the on-screen keyboard by default, add a button to toggle the display of the on-screen keyboard.
It might also be prudent to give the on-screen keyboard the ability to be resized.
Edit to answer question:
Keyboard should be hidden by default if most of your users are going to be on a computer,
Visible by default if most of your users are going to be on a mobile device.
You can consider checking the display size. If the display size is smaller than a certain size, you can assume that it is a mobile device and can display the Arrow Buttons. Other wise use keyboard buttons.
You can also keep an option so that user can set this manually if needed.
You could use javascript to find out the height of the windows view port and then us an if statement saying:
if ($(window).height() <= "960")) {
//Your code to display keyboard controls
//P.S. 960 is height of iPhone 4+ screen
}
Edit: Left out ) at end of $(window).height() <= "960"