TextInput iOS7: text is being moved vertically as soon as the input is being focussed

[AlBirdie]

As reported in Issue #694, I'm still having the issue that the TextInput's text is being moved down about 3 pixels once the input is being focussed. I've got this with all my TextInput instances on iOS7.

This is what happens;

Create a a regular TextInput (it actually doesn't matter whether typicalText is being set or not), and set a prompt. As soon as you run the application, you'll immediately notice that once you focus the TextInput, the cursor isn't vertically centered. The prompt stays centered. Start typing, and text sits right where the cursor is, thus not centered. Set focus to another control and the text will be centered. Focus the TextInput again and the whole text will be moved down to the cursors initial position, which happens to be roughly 3 pixels off center.

I'm running on iOS7 with AIR 3.9 build 960, Starling 1.4 and Feathers master from today. This appears only on iOS7, Android and iOS7 are fine.

Hopefully you are able to reproduce the issue.

[joshtynjala]

I cannot reproduce this issue on my iOS7 devices.

[AlBirdie]

That is really odd. No idea what might cause this issue. Device DPI maybe? Have you tested non-retina devices as well? I'm going to update to the latest AIR 3.9 now and see how it goes.

Unfortunately, no luck with this either. No idea what is happening here since even our styles are identical to your MetalWorksMobileTheme, apart from the font of course.

Debugging the StageTextTextEditor class also showed that stageText.viewPort.y actually remains identical, yet once it receives focus it moves down and up again as soon as it loses focus.

[joshtynjala]

I don't have a non-Retina device that runs iOS7. I have iPhone 3GS and iPad 1, but they are both stuck at older versions now.

Can you try testing a plain StageText? If that fails, we know it's a runtime bug.

[florianbernard]

I'm facing the exact same issue. Tested on iPhone 5 & iPad mini (AIR 3.9 / iOS 7).

Here are some screenshots:

• https://dl.dropboxusercontent.com/u/10483409/app/IMG_4368.PNG
• https://dl.dropboxusercontent.com/u/10483409/app/IMG_4369.PNG
• https://dl.dropboxusercontent.com/u/10483409/app/IMG_0002.PNG
• https://dl.dropboxusercontent.com/u/10483409/app/IMG_0003.PNG

With AIR 3.8, everything was fine.

[joshtynjala]

Looks like the X button on the right is in the correct location, and it's just the text being pushed down. It seems even more like a StageText bug. As I said, though, I cannot reproduce the issue on my devices that run iOS 7. I have iPod Touch 5th gen and an iPad 3.

[florianbernard]

Josh, just tested with a plain StageText and I notice the exact same issue.

Do you think it can be related to the new status bar behaviour? Though, the Y offset seems not equal to the bar height.

Can you share the issue with Adobe?

[joshtynjala]

If it happens when the status bar is visible, but not when in full screen, then yes, it could be related to the new behavior. I think I only tested in full screen, actually, so maybe that's why I'm not reproducing it.

I submit bugs on http://bugbase.adobe.com just like anyone else. If you submit it, I'll vote for it. If you want me to submit it, you'll need to find a way to get it to reproduce on one of my devices. I'm not comfortable submitting a bug that I can't reproduce myself because I can't properly respond if Adobe follows up with questions.

[florianbernard]

Just tried again with the status bar hidden - same issue. Will create a ticket on JIRA and post the URL here.

[florianbernard]

https://bugbase.adobe.com/index.cfm?event=bug&id=3648234

[joshtynjala]

After some random tweaks while trying to reproduce another issue, I am now able to reproduce this one. It appears that when StageText is single line, on iOS 7, the text is aligned to the bottom of the view port. The larger the view port's height, the further down the text will appear.

[AlBirdie]

Glad so see that you guys were able to reproduce this. Though I'm still wondering what the differences in Josh's test project and Florian's any my project are. There have to be minor things that aren't identical so that he, Josh, wasn't able to reproduce this from the very beginning. I'm really interested because, based on the feedback in the Starling forums, there aren't many others that ran into this with AIR 3.9 as well.

Josh, yes, there's definitely an inconsistent behaviour concerning the movement itself. I've seen the text move down one pixel for a TextInput positioned at the top of the screen, and about 3 pixels for one that sits right at the bottom.

[joshtynjala]

The difference is the height of the StageText. As I noted, the text is aligned to the bottom. If you increase or decrease the height of the StageText, the amount of pixels the text will be "moved" will change. It used to be aligned to the top in previous versions, so it didn't matter what the StageText's height was.

[joshtynjala]

By the way, the workaround for TextInput would be to increase the paddingTop and paddingBottom values to ensure that the StageText's viewport height is as close as possible to the height of the displayed text. Since the text is aligned to the bottom, you want the height to be small enough that you force it to the top.

[AlBirdie]

I'm not entirely sure if the StageText's height is the sole cause for this issue. In fact, all my TextInputs have the same height (88 * scale, identical settings like in the MetalWorksMobileTheme), thus StageText should have an identical height throughout the entire application as well. However, there are still differences concerning the amount of pixels the TextInput's text is being moved. Also, the workaround with different paddings doesn't work for me. I've tried with various padding settings, yet I don't see any difference. Could you maybe post some of your settings here?

[joshtynjala]

Setting paddingBottom to a larger value on TextInput will make the height of the StageText smaller. Basically, you're trying to get the height of the StageText to be equal to the height of its text, so that it is aligned to the top instead of the bottom.

Do your TextInputs that have identical height have identical font sizes too? If they don't, that explains it. The text height will be different in that case, so it will appear to be moved down a different number of pixels.

[AlBirdie]

All TextInputs share the exact same properties, however, it seems as if the StageText's height isn't the issue here. Well, at least for me it isn't. What I'm experiencing is that the amount of vertical movement is largely dependent on the position of the TextInput on the screen. TextInputs that sit right at the top of the screen, so y = 0(ish) cause a much lesser vertical StageText movement than TextInputs that sit at the bottom of the screen. For the latter, the cursor is actually placed almost entirely beneath the TextInput.

[joshtynjala]

I see. Well, someone from Adobe said that they could reproduce, so we'll see how it goes. You should probably add a note on the Adobe bug to explain what you're seeing so that they test that case.

[AlBirdie]

Good idea. I'll add some screenshots as well. Hopefully they can fix this in the (very) near future.

[AlBirdie]

Just a heads up, the StageTextTextInput's position not matching the Feathers TextInput's position when focussed (as seen in the screenshots in #736 was a stupid mistake from me thinking that moving the Starling viewport down by 40 pixels for the retina iOS7 devices would solve the "issue" of the iOS status bar overlaying the content. The original issue remains, though.

[joshtynjala]

If that's your issue, and it's no longer valid, you should close it.

[IngweLand]

Have similar issue.

Setup: 1) iPad 3 with iOS 7 2) Latest AIR, latest stable Starling, latest Feathers from github 3) Embedded font and TextFieldTextEditor

What we have: 1) On focus in: font is wrong - not what was embedded; text is correctly vertically aligned in the middle; "delete" icon at the right is correctly vertically aligned in the middle 2) On focus out: font is correct; text appears to be aligned to the top of text input (wrong); text is not smoothed (wrong) 3) When gaining focus - second "instance" of the text blinks one time - the instance which was at the top when text input did not have focus

Here is the very basic code:

package
{
    import flash.text.TextFormat;

    import feathers.controls.Label;
    import feathers.controls.TextInput;
    import feathers.controls.text.TextFieldTextEditor;
    import feathers.controls.text.TextFieldTextRenderer;

    import starling.display.Sprite;
    import starling.events.Event;

    public class Main extends Sprite
    {
        [Embed(source="MyriadPro-Regular.otf", embedAsCFF="false", fontFamily="MyriadPro")]
        private static const Font1:Class;

        public function Main()
        {
            super();
            addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
        }

        private function onAddedToStage():void
        {
            var l:Label = new Label();
            l.x = 20;
            l.y = 100;
            l.textRendererFactory = function ():TextFieldTextRenderer
            {
                var format:TextFormat = new TextFormat("MyriadPro", 60);
                var renderer:TextFieldTextRenderer = new TextFieldTextRenderer();
                renderer.textFormat = format;
                renderer.embedFonts = true;
                return renderer;
            };
            l.text = "Sample text";
            addChild(l);

            var ti:TextInput = new TextInput();
            ti.x = 20;
            ti.y = 300;
            ti.setSize(500, 100);
            ti.textEditorFactory = function ():TextFieldTextEditor
            {
                var format:TextFormat = new TextFormat("MyriadPro", 60);
                var renderer:TextFieldTextEditor = new TextFieldTextEditor();
                renderer.textFormat = format;
                renderer.embedFonts = true;
                return renderer;
            };
            ti.text = "Sample text";
            addChild(ti);
        }

    }
}

[elalienx]

Hi the bug also happens on Android (Nexus 7 2013 stock android) and iPod touch 5 gen with iOS7. Only on iPad works well

[joshtynjala]

Check if the aspect ratio of the Starling stage and the Starling view port are different. If that's the case, the StageText cannot be reliably positioned over Starling because Starling will be stretched or squished a bit.

[elalien]

Hi, yes the original app was developed on a 480*320 (1.5 ratio) and the app adapts to any resolution just as proposed by the starling manual http://wiki.starling-framework.org/manual/multi-resolution_development

And now that I check on the iPad air there's a little offset by a few pixels because the ratio on the iPad is 1.3 but on the iPod touch (same ratio as an iPhone 5) an the nexus are more than 1.775.

So the question is: There´s a workaround to this? Thanks for the quick reply by the way.

Edited: Spelling.

[joshtynjala]

Which "strategy" are you using for multi-resolution? The issue with the text being offset when the TextInput receives focus applies to Strategy 1, and even the Starling Manual tells you over and over again not to use this strategy.

The other strategies should work just fine with TextInput. Last time I tested TextInput with Strategy 2, it was working correctly. I haven't personally tested Strategy 3, but it should also work because it uses the same aspect ratio for the stage and the view port.

[elalien]

Don’t worry it’s not the strategy one (because stretching is awful, just scaling 1024*768 to retina iPad looks bad). Actually its number 2 the one asking if its iPad and just like the last paragraph suggest do the same with the iPhone 5, and creates a rectangle for the viewport that passes the screen width and height.

The "main" class actually was modified based on the demo "scaffold mobile" that comes with the examples of Starling 1.4. (By the way I’m using Builder 4.7 with Air 3.9, Starling 1.4 and started the project with Feathers 1.1 and the switch to 1.2 the day after release but the issue appeared before switching to 1.2)

P.D I will move this to the official forum, seeing that its not related to issue #701

Thanks for the feedback

[AlBirdie]

Since I've opened this issue, I just wanted to check whether there are still people that have issues with the TextInput somehow being moved on iOS7. I've tested this on iPad2/3/4 Mini/Mini Retina and didn't see any issues, which is why I'd like to close it.

[joshtynjala]

It's been 7 days since you asked, so I'll close it for you.

[ZwickTheGreat]

I am having this issue with iPhone5 since Adobe AIR 3.9 (3.9 and 4.0 tested) App packed with 3.8 is OK.

I am wondering that both issues are marked as closed.

[AlBirdie]

Because you are 22 days late with your comment, simple as that. ;)

In all seriousness, I couldn't reproduce the issue on iPad (which is where I first discovered it), so I figured it has been solved. In fact, the issue was basically my own fault not setting the Starling viewport properly. If you are still having issues with your project, please post a detailed description of what you're doing, ideally with some source code, in the Feathers support forum.

[ZwickTheGreat]

When I build project with 3.8 it's working OK, but when I try to build the project with 4.0, sadly, StageText's content is moved about ~40 pixels everywhere on the screen. It almost looks that it's moved by the ios7 status bar height. The X button is always in correct position.

[AlBirdie]

Again, please post the relevant code passages.

[ZwickTheGreat]

Have created simple project. Four different TextInputs. Two with paddingTop.

package {
    import feathers.controls.TextInput;
    import feathers.core.FeathersControl;
    import starling.display.Quad;

    /**
     * Starling main.
     * @author Jakub Wagner, J4W
     */
    public class MainStarling extends FeathersControl {

        public function MainStarling() {

        }

        override protected function initialize():void {
            var textInput0:TextInput = createTextInput();
            textInput0.setSize(300, 20);
            textInput0.y = 50;

            var textInput1:TextInput = createTextInput();
            textInput1.setSize(300, 40);
            textInput1.y = 100;
            textInput1.textEditorProperties.fontSize = 30;

            var textInput2:TextInput = createTextInput();
            textInput2.setSize(300, 80);
            textInput2.paddingTop = 20;
            textInput2.y = 200;
            textInput2.textEditorProperties.fontSize = 30;

            var textInput3:TextInput = createTextInput();
            textInput3.setSize(300, 120);
            textInput3.paddingTop = 40;
            textInput3.y = 300;
            textInput3.textEditorProperties.fontSize = 30;
        }

        private function createTextInput():TextInput {
            var textInput:TextInput = new TextInput();
            textInput.backgroundSkin = new Quad(100, 100, 0xC0C0C0);
            textInput.backgroundFocusedSkin = new Quad(100, 100, 0xE9E9E9);
            addChild(textInput);
            return textInput;
        }

    }

}

On iPad 1 (iOS6): https://dl.dropboxusercontent.com/u/47425848/TextInputBug/iPad_1.png On iPhone 5 (iOS7): https://dl.dropboxusercontent.com/u/47425848/TextInputBug/iPhone_5.png

FlashDevelop sample project: https://dl.dropboxusercontent.com/u/47425848/TextInputBug/StageTextTestProject.zip

Forum link: http://forum.starling-framework.org/topic/ios7-textinput-bug-wrong-vertical-padding

[AlBirdie]

Nothing wrong with your code. So yes, the original issue seems to be still in place. Very interesting since I haven't been able to reproduce this one since. Did you try Josh's suggestions about different paddings for the TextInputs? That might work as a workaround. I currently don't have an iPhone5 at hand so I can't give you any detailed advice at the moment, sorry.

[ZwickTheGreat]

Ha! I've just found this workaround. If I set both paddingTop and paddingBottom, it seems to work! https://dl.dropboxusercontent.com/u/47425848/TextInputBug/iPhone_5_workaround.png https://dl.dropboxusercontent.com/u/47425848/TextInputBug/iPhone_5_workaround2.png

...
            textInput2.paddingTop = textInput2.paddingBottom = 20;
...
            textInput3.paddingTop = textInput3.paddingBottom = 40;

But still have no clue, why it's iOS7 and AIR4.0 related... :-1: