This will be difficult to explain so I won't paste any code.
I'm implementing a wysiwyg editor on my site called wysihtml5 and there are several issues when selecting the textarea/editor with the iPad. On a desktop browser, all is fine, the text can be selected, edited, pasted etc. But on the iPad multpiple issues occur:
Can't tap anywhere in the text to move the cursor there
If I manually move the cursor, all of a sudden I can't type anything anymore
Tapping outside of the texteditor doesn't bring the keyboard down
Basically I'm just hoping there's someone who has had similiar experiences with iPad cursor not behaving correctly in text input fields and what possible solutions there might be. I'm stuck and have no idea how to debug this.
Did you use touch event? iOS has a bug: you can't input in editable iframe if you are listening(or had listened) any touch event(touchstart, touchmove...), I tested this bug occurs even you listen other elements but iframe itself. yes, it's a serious bug, you can check out:
wysihtml5 issues98
Related
We have a PWA (web app) that the user can add to the homescreen to make it look more like an app. Some users have reported a strange issue that only seems to appear on IOS sometimes when the following step has been made.
Open the app from the homescreen
Use the app for a while
Put it into background
Turn off the screen for a while
Turn the screen back on and put the app to foreground again
The bug is that nothing seems to happen when you click on a select or date input control. First I thought that there was some overlay in the app that was blocking the ui controls but the elements receive focus on click, but not options are shown.
Now it really becomes strange. When I tried to click a little bit under the select input an option was selected. The same thing occured with a time select. If I first clicked on the timeselect input control and then a little bit under, it updated the time.
So, the controls seems to be there but nothing is visible on the screen. I have only been able to reproduce this on my own once but multiple users have been reporting the same thing. The only way to work around the bug is to restart the app.
It seems to be for all native safari controls that shows some kind of modal/popover.
I've did an indepth investigation on this select dropdown problem and posted an issue at bugs.webkit.org: https://bugs.webkit.org/show_bug.cgi?id=238318
It's a problem with dropdowns of several components (such as select, input file/date/month) where either the animation to have the dropdown appear or disappear seems to get stuck. You can sometimes see the dropdown being tiny and very transparent (if you zoom into a screenshot) and sometimes you'll be able to select an option even though you don't see the dropdown.
I am working on ionic application.I have a problem with keyboard in iphone 4s with iOS 9, when I click on any text field the keyboard pops up but, I can't see cursor and what I am typing in the input textbox, it shows nothing when I type, but when I change my focus to another field, the text automatically appears. Anyone has got the same issue? What did you do to rectify it?
First take backup of your project then,
You need to remove all your controllers, texts, buttons,styles from that view, and then add them brick by brick
everytime make build of it and check it, by this way you will get your solution.
for me it was css of h3 tag.
that was hiding text in input.
I've got an app that uses a web view where text can be selected. It's long been an annoyance that you can't select text across a block boundary in UIWebView. WKWebView seems to fix this with a property on its configuration: selectionGranularity. One of the possible values is WKSelectionGranularityCharacter:
Selection endpoints can be placed at any character boundary.
Sounds great! Exactly what I need. Except that when I set that in my web view, I often can no longer select text at all. What is going on? Is there something else I need to set? Has anyone figured this out?
Update: I've figured out the following bugs:
When there is more than one WKWebView in an app with selectionGranularity set to WKSelectionGranularityCharacter, only the most recent one to load can select text. I've filed this as bug 18441138.
If there is a click handler attached to an element inside the body in the HTML content of a WKWebView whose selectionGranularity is set to WKSelectionGranularityCharacter, text selection doesn't work inside that element. I've filed this as bug 18440833.
Text selection fails in the WKWebView after you've entered edit mode on a UITextView somewhere else in the app until the WKWebView reloads. I've filed this as bug 18468405.
Has anyone worked around any of these?
These and other issues are all fixed as of iOS 13.
There are several known bugs that are still not fixed.
You can execute JavaScript to get selected text as a workaround.
window.getSelection().toString()
Docs
I have a Windows Phone 8.1 app. I have a webview and a TextBox in same grid on a page. TextBox is for copying text to clipboard so the user has to interact with it to copy the text. I am using the visibility.collapsed to Show the webview or to collapse it and Show the TextBox.
The Problem occurs when I use the webview and then collaps it and Show the TextBox, I can't interact with the TextBox any more. I can tap on it and it Looks like focused but I can't interact with it. I can't copy the text or mark it for copy. I must also say that a messagebox appears when switching from webview to TextBox (I did this). maybe this is impoortant for you.
How can I bring the TextBox's functionality back? And the funny Thing is that sometimes (rarely) it works. But when it is not working any more than it doesn't work until you Close the app completely and open it again.
I have a form that appears in a FancyBox iframe modal. On iOS 5 (specifically on an iPhone - does not occur on iPad) when I touch the submit button it activates a <select> that appears about 50 pixels above the submit button and I'm then presented with the <select> options at the bottom of the screen.
I've zoomed in as much as possible to verify that I'm not touching the select – I am indeed clicking on the submit button and it highlights itself as expected, but the form of course does not submit and I get the options to pick from.
Has anyone experienced a bug like this in iOS 5? I can't pin this down to anything else – there is some javascript that would normally run to process the form on submit click but it's not being activated at all and it has no effect on the form itself, the <select>, etc. I have seen several odd things with iframes on iOS and wonder if there is a potential correlation.
You might have the connections for your actions going to different buttons than the outlets. That would explain why the right thing would happen (Action is OK) but updating the Frame Rect would get messed up (Outlet is on the wrong button).
iframes on ios don't behave like normal iframes in every other browser (including desktop safari).
ios safari renders them at the full height of the page inside the iframe.
To get them to scroll like a normal iframe of fixed height you have to put them in a div and set the divs overflow to auto or scroll. I'm guessing your modal overlay is already doing that.
But even a plain in-page iframe with no special positioning (other than using a parent div to crop its height and make it scrollable) will often only have the submit button work 1 time if the submit buttons original rendered location was below the fold of the parent div.
So the first submission will work, but if the form comes back with missing required field errors you can't hit the submit button again.
Further research on my old ipad shows that if the submit button is down far enough it won't even work that first time.
The bug is present in safari for ios 5.1.1 and also ios 8 !!!
I can use an onclick javascript function on any element in the iframe that is not an input type=submit to force the form to form.submit().
But specifically about the iphone issue what was probably happening was that the OS was trying to zoom in to the form field so the use could clearly see what they were typing. The fix for that might be to declare a font-size of at least 16px on input elements. That way the OS knows the text in the field is already at a fairly readable size and won't try to zoom in. Zooming in to the contents of an iframe within an absolutely positioned modal overlay is super buggy even in ios 8.