I am creating an Ionic 2 mobile app and am having some problems with input fields and keyboards. For now, I am only referring to iOS. This is the page without any input activated.
Now, If I tap on CVV or Postal Code input fields, the keyboard does not push the ion-content up so the cvv or postal code fields are in focus above the keyboard.
If I tap on postal code field, the entire input is covered by the keyboard. No scrolling happens. Before this issue, when the keyboard would open the content would squeeze up above the keyboard, but the content would squeeze, not push up off the screen if it is too large to fit the content.
Anyone have advice on how to do this? I do not think it requires any plugins to control the content or keyboards. It seems to have something to do with styling with percentages.
I need to see some page code to help, but i had this problem too and solved by doing:
Wraped all my inputs on <ion-item> tags.
Used ionic input tags (not the regular <input> tag).
Put all inside a <form> or <ion-list> (what you probably have done).
Without this i was having issues of fields remaining static where they are and focus errors on many input types (textarea being the one with more errors).
For scrolling pb, i wrote a hack here : https://github.com/ionic-team/ionic/issues/10629#issuecomment-395084125
In the constructor of app.components.ts :
window.addEventListener("keyboardDidShow", () => {
document.activeElement.scrollIntoView(false);
});
Related
I’m looking to create a pop up where by the user inputs data, then select one of two radio options by the UI seems to screw up when I have a combination of both text type and radio type in a pop-up.
Here is my code:
I was also looking for same thing today.
But look at this discussion, which says mixing of radio, checkbox or text box is not available right now.
I also tried to add mixture of radio and text field in alert. But styling never appeared correct.
I am moving on to implement this feature using a ionic page so that I can use Ionic Modal. This behaves as a modal window on large screen and as pushed page in smaller screen.
I needed to send back data from parent page to child page and other way too. Thus Ionic Modal suited best for this in my situation which can be used on component/page.
Refert to this detailed usage instructions for Ionic Modal.
Same feature has been requested from Ionic team.
I am having a strange bug in ios safari where a position:fixed sidebar with an input in it which allows a user to perform a search query. Everything is fine when to scrollTop of the page is 0 (no scrolling occurred, top of page). At this state the input is focusable and the user can enter stuff in the input. However when the user scrolls a few pixels down the input is no longer focusable and the user can not input anything, nor does the keyboard show.
Anyone else ever encountered this bug or know a fix/hack that could solve this?
Thanks,
K.
This is not bug, when you tap the textFiled it becomes FirstResponder and you can enter text in it using keyboard. When you scroll the scrollView, textField will resign as FirstResponder and scrollview will become FirstResponder. So now you want be able edit text in textfield unless you tap it again.
Regarding keyboard not showing up, this is because when textfield resigns as FirstResponder it will call textFieldShouldEndEditing: delegate method and you might be returning YES in this method.
I changed all fixed containers to absolute positioned containers and now it works. Guess position:fixed still has some side effects in ios safari.
As part of my login and registration forms, if there are errors then it will autofocus the related field. Actually, it not as simple as I thought. Let me try to explain!
Basically, on this project, pages are loaded with AJAX. Forms may include an autofocus attribute. This works great, but on mobile it just shows the cursor without bringing up the keyboard, meaning you still have to tap the input to start typing.
Am I missing something, or do I have to double-up the focussing with something like
document.querySelector("[autofocus]").focus();
// with appropriate verification that the element exists, of coursr
In mobile devices (at least in Apple's Safari), the keyboard isn't allowed to show up without the user clicking on the input field. It's by design, and I don't think there is much you can do about it.
http://www.quora.com/Mobile-Safari-iPhone-or-iPad-with-Javascript-how-can-I-launch-the-on-screen-keyboard
I was delighted to discover that Android 2.2 supports the position:fixed CSS selector. I've built a simple proof-of concept, here:
http://kentbrewster.com/android-scroller/scroller.html
... which works like a charm. When I attempt to add an INPUT tag to my header, however, I hit trouble. On focus, every device I've tried so far clones the INPUT tag, gives it an infinite Z-index, and repaints it on top of the old tag. The clone is in roughly the right position, but most of its parent's CSS (including, of course, position:fixed) is ignored. The cloned INPUT tag is the wrong size and shape, and when I scroll the body of the page, it scrolls up and off the screen.
Once it's off screen, hilarity ensues. Sometimes the device will force the scrolling part of the body back down so the cloned blank is back in view; sometimes the keyboard goes away even though the visible box seems to remain in focus; sometimes the keyboard cannot be dismissed even though the INPUT blank is clearly blurred. Here's an example you can run on your Android 2.2 device to see what's happening:
http://kentbrewster.com/android-input-style-bug/
Styling input:focus has not done the trick for me yet, nor have many different brute-force attempts to listen for focus() and blur() with JavaScript and do the right thing with focus and the keyboard.
Thanks very much for your help,
--Kent
This will probably not be resolved until Android switches to using Chrome for its WebView. The current Android browser creates an Android TextView on top of the page when an HTML input field is focussed. Apparently they don't style or position it correctly. You can see it go more wrong on pages that use contentEditable.
The current Chrome-for-Android implements the WebKit IME interface, so input fields are drawn by WebKit (and lose some of the niceties of the Android TextView on ICS) and shouldn't have issues like this.
The solution is to add:
input {
-webkit-user-modify: read-write-plaintext-only;
-webkit-tap-highlight-color: rgba(255,255,255,0);
}
in your css.
You might be able to solve it by using a bug in Android: http://code.google.com/p/android/issues/detail?id=14295.
That is, don't display the input field right away. Instead, display an overlay div which listens on click and hides itself and shows the hidden input, and give the input focus. This somehow prevents Android from using the wierd input that gets placed on top of everything, and is instead using the browsers input field which you can style any way you want.
As you'll note in the bug raport though, this doesn't work with input[type="number"]...
Basically, what I want to do is put some buttons before the tabs in a gtk.Notebook. I tried making my own notebook type widget and it worked well, but it would have required lots more work to make it as flexible as I would like, also it wasn't as efficient.
Here is a mock-up of what I'm trying to achieve: http://imagebin.ca/view/84SC0d.html
Any ideas would be much appreciated, thanks.
Ben.
You might be interested to know that this functionality has been added in GTK 2.20, see "Changes in GtkNotebook" in the following announcement: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00132.html
It's a hack, but you can put your widgets on a separate tab, and then prevent the tab from being clicked by registering the following switch-page event for the notebook:
def onTabsSwitchPage(self, notebook, page_notUsableInPython, pageNumber):
# Don't allow to switch to the dummy tab containing widgets
if pageNumber == <put correct tab number here>:
notebook.stop_emission("switch-page")
Note that this doesn't look good with all GTK themes, but it works...
I don't think there's any way to do it without making your own notebook widget. There are a couple of hacks. One was posted by AndiDog. Another is to hide the tabs altogether (notebook.set_show_tabs(False)) and make a toolbar with buttons above the widget, with your buttons on the left, plus one button for each tab in the notebook that switches to that page.
Instead of making your own notebook-type widget from scratch, you could inherit from gtk.Notebook, overriding some of the methods like expose_event, size_request, and size_allocate, in order to deal with two types of container children: pages and buttons. I don't know how to do this in PyGTK though, only in C.
You might also consider whether the buttons in the tab space are really what you want. What if the user resizes your notebook small enough that some of the tabs disappear? Where do the previous tab/next tab arrows go? What happens to the buttons?