Good morning everybody working with Gluon Mobile
I have the problem of a javafx.scene.control.TextArea staying on the screen like a layer after switching the view, that is, after calling
Application.getInstance().switchView(...)
from a screen with a TextField and this TextArea arranged inside a VBox (with consent from Gluon, I used the code from their Notes example). The isolated TextArea then appears as if it was layered over the other screen to which the switch took place.
This happens on the iPhone / iOS only, and only if the text area had the focus at least once. On the desktop as well as under Android, or when the focus was never in this TextArea, everything works fine.
Does anybody have an idea what could cause this effect?
Regards
Martin
Related
I am developing an app (IOS platform) using HTML5, CSS3, angular and cordova(3.8) and stuck with an major issue.
I have a page with footer having three buttons. On click of each button a modal comes up from the bottom. Modal position is set to fixed and inside it as scroll-able container. scroll-able container contains a text area where user can input some text.
Whenever the modal comes up, text area is focused so that keyboard comes up by default. The issue is whenever native keyboard comes up webview is pushed up and entire modal gets scrolled.
I saw same issues been posted by others and I tried few solutions mentioned in reply for those questions like using ionic keyboard plugin, setting scrollTop to 0 on textarea focus. But nothing worked out.
In config.xml, I have set DisallowOverscroll to true.
It would be great helpful if someone help me with this issue ?
I have an interesting issue with an IOS app, 32bit at present.
I have a simple project with one form, a button and a TWebBrowser component.The "onclick" of the button sets the align property of the twebbrowser to client and opens a webpage (www.trademe.co.nz for testing).
Every thing works ok until I go to use the virtual keyboard (e.g. enter a search). When the virtual keyboard appears I am getting a second "done" button bar appearing above (and behind?) the main one. The main "done" bar includes next and previous buttons, whereas the background one doesn't. It appears that there are two keyboards appearing. I have the issue on both my test phones, one running IOS7 and the other running IOS6 and I believe it is also happening under IOS8.
Does anyone have any idea what causes this?
TIA
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
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.
I am writing an app for IOS and Android using Flex 4.6. Everything is working fine on Android, but on IOS after the softkeyboard appears and the screen pans, when the keyboard is dismissed the screen never pans back down. The bottom half of the screen stays white and the top half remains shifted out of view. I have been searching online and through my code trying to figure out what could be wrong and I've had no luck. I have been running the program in debug mode, but no AS3 error messages are shown. My trace()s are printed, and the app will continue to work but obviously you are unable to interact with the top half of the app. Everything works fine if I set the softkeyboardBehavior in the XML to none, but then the user can't see where they are typing.
I have only been able to test this on my IPod touch with IOS 5.0.1. When I try to run my project in Flash Builders simulator neither the Android nor the IOS version will get past the splash screen.
Any help would be greatly appreciated
Thank you
I have seen that the softKeyboardDeactivate event from TextInput is not fired, as other actions that the unpan should cause are neither fired.
It seems it's a Flex 4.6 version bug. (http://forums.adobe.com/message/4068144).
I've found a workaround, it's a little tricky but it works.
Put a new TextInput hidden on top of the View, then on focusOut event on the original TextInput, force focus on the hidden TextInput. Softkeyboard event will be activated for that TextInput and the pan will return to the top of the View, then take off the focus from the new TextInput and the softkeyboard will disappear.
The user will not notice about this tricky solution.
<s:TextInput id="ghost" x="-100" y="0" width="0" height="0"/>
<!-- ... -->
<s:TextInput id="original" focusOut="textInputFocusOutHandler(event)"/>
...
public function textInputFocusOutHandler(event:FocusEvent):void
{
this.ghost.setFocus();
callLater(this.setFocus);
}
Try adding the "enter" attribute to your TextInput. It worked for me but now I have the issue where it jumps vs. pan when the soft keyboard deactivates.
It seems that my problem was that I was using the StageText skin for my text boxes, which adobe says in the documentation causes panning and any type of scrolling not to work. Switching to the old TextInput skin seems to fix the problem, but you loose all the native features for the soft keyboard, which pretty much ruins your user experience unfortunatly.