StageText bug with runtimeInBackgroundThread=true on Android

[Mintonist]

Hi! I use AIR 51.1.2, Starling 2.7 + Feather 4.1

Packaging Android build with <runtimeInBackgroundThread>true</runtimeInBackgroundThread> cause a bug in textfield with StageTextTextEditor - text is disappear when softkeyboard is hidden

https://github.com/user-attachments/assets/3f94bc35-06a2-4e59-8e1a-c2f88444f20f

(you can use "save as" for embedded video)

It's probably a bug in AIR related to StageText.

I need use Feather StageTextTextEditor (which use AIR StageText) to correctly display emoji.

[ajwfrost]

I'm not able to see the video (I don't see any 'save as' option that doesn't result in me trying to download the html website..) but I think it's clear what you're seeing.. we can check on this one; likely just another issue with the background thread synchronisation/side-effects..

thanks

[Mintonist]

Try attach as webm video_2024-12-03_22-08-42.webm

[ajwfrost]

Thanks, we can see that video now - it seems like the text is saved but just not present when the StageText element isn't actually active. We'll see whether we can reproduce this just with StageText and if not start adding in Feathers to see how they capture the text/display..

thanks

[ajwfrost]

Hi @Mintonist - struggling with being able to reproduce this here, I'm wondering if there are subtleties in the set-up that we'd missed.. Are you able to to reproduce the problem if you have a really basic Feathers app with just a text input control on the screen? Wondering if you could provide the SWF + XML file so that we can check with that..

thanks

[Mintonist]

Hi @ajwfrost! DemoStarling_2024.12.06.zip

[ajwfrost]

Great, thanks .. and there's the problem:

2024-12-06 18:02:07.919 28967-29053 AdobeAIR                air.com.demo                         W  Attempting to capture snapshot of StageText whilst running in a background thread

So basically Feathers is using StageText.drawViewPortToBitmapData() to capture the snapshot of the StageText element, in order to upload that to the Starling texture for display. But in the 'background' mode, we cannot call the necessary function to render the Android native text element into a bitmap, because we're not on the Android UI thread..

I have a feeling we had found that we're not able to sync the threads for this one, but I'll double-check that with my colleague, since we do seem to have synchronised the add/remove stage calls... failing that, we'd need to adjust this to provide an asynchronous mechanism (like we did with StageWebView, on Windows at least) which would also then need a code update to Feathers..

thanks

[Mintonist]

Thanks a lot for all your work! Can you advice an other way to display StageText into Starling display list?

[ajwfrost]

Hopefully we can avoid needing an asynchronous render here .. are you able to try with the attached, to unzip into lib/android/lib folder? It may need to be on top of 51.1.3 though.. runtimeClasses.zip

thanks

[Mintonist]

Hi!

Yes it works now!

New problem - first call setFocus() on each TextInput is trigger soft keyboard but textfield is stay invisible. Second call works fine. Only for <runtimeInBackgroundThread>true</runtimeInBackgroundThread>

Demo - DemoStarling_2024.12.07.zip

[ajwfrost]

Okay so this appears to be due to the asynchronous nature of things now.

1. You call setFocus() on the text editor which passes this through to the AS3 StageText object
2. In Android/Java, we push the request to display/set focus onto the StageText instance - in the UI thread
3. SO the focus events are now asynchronous, we have to get that UI thread to queue up the AS3 event on the background thread
4. In Feathers, it's checking for whether the StageText has focus...
5. If not, it's hiding the StageText instance ..

https://github.com/feathersui/feathersui-starling/blob/master/source/feathers/controls/text/StageTextTextEditor.as#L1269

So, we need to find a way to dispatch the FOCUS_IN event inline with the request to set the focus. I think it will be possible to refactor some of the code for this, or perhaps to synchronise the threads a little more..

[ajwfrost]

.. and the problem with using "preview" is that the above message was just sat there for a while without being sent. We now have a fix candidate for this part too .. please let us know of any other feedback!!

thanks runtimeClasses2.zip

[Mintonist]

In my project all works properly! Thx!

[ajwfrost]

Great, thanks for confirming..

[Mintonist]

Unfortunately I noticed a problem without <runtimeInBackgroundThread>true</runtimeInBackgroundThread> If textfield is placed near screen bottom and moved with opening soft keyboard - i see bugs with black screen. Can your fixes change behavior for <runtimeInBackgroundThread>false</runtimeInBackgroundThread> ?

[ajwfrost]

Hi @Mintonist - can I check, are you using that same test case and moving everything to the bottom of the screen? If I do that, then I can click on the screen and the keyboard pops up but then sometimes this obscures the text area/border, until you click again. So it looks like the rest of the screen is black..

Or do you mean, a normal application is running with content everywhere on the screen, but when you click on a text field low down, the screen goes fully black whilst the keyboard appears? (A video may help, if that's easy to do!)

And is this (1) only happening with our patch release above, or (2) an existing/separate issue in the published AIR SDK?

I'd wanted to trigger a release of the AIR SDK to fix a few other bugs, so it's a case of deciding whether or not this black-screen thing is a side-effect of the above changes, and whether then it's better to keep the original bug, or to put the fixes in so that we end up with this new bug ...! (I'm aware those aren't ideal options, but a bit time-limited at the moment!)

thanks

[Mintonist]

I use your last link https://github.com/user-attachments/files/18061912/runtimeClasses2.zip and replace it in AIR51.1.3

With <runtimeInBackgroundThread>true</runtimeInBackgroundThread> it works.

But I decide to upload build with <runtimeInBackgroundThread>false</runtimeInBackgroundThread> (as I did before). And noticed such behavior (there is crash in the end):

https://github.com/user-attachments/assets/59e844a5-ed33-4d64-814e-61877e723a7e

adb logcat file - log.txt

So it is you variant:

a normal application is running with content everywhere on the screen, but when you click on a text field low down, the screen goes fully black whilst the keyboard appears

There is no crash without runtimeClasses patch! So I use runtimeClasses from distributive for my builds.

P.S. Seems it happens with every StageText in any screen position.

[ajwfrost]

Thanks @Mintonist .. that log is showing a VMPI_failFast() call (see the register values...): https://github.com/adobe/avmplus/blob/858d034a3bd3a54d9b70909386435cf4aec81d21/VMPI/VMPI.h#L763

	#define VMPI_failFast() do { volatile unsigned* crash = 0; *crash = 0xdeadbeef; } while(0)

And this is happening within the StageText object's Focus event handler but when we're hitting an unrecoverable stack overflow issue .. so I suspect there's something here that's causing recursion, where one event is triggering another and they're then just calling repeatedly until the process runs out of stack space, can't recover, and is aborted.

We couldn't reproduce that here, but I'll take the changes out of our 51.1.3 branch before we do our next release, and ask someone to double-check and investigate this further!

thanks

[Mintonist]

@ajwfrost I see this ticket mention as closed in AIR 51.1.3.2. Does it mean that "an unrecoverable stack overflow issue" is closed?

[ajwfrost]

Hi

I'm afraid we only put in the partial/original fix there - for the bitmap rendering of an async StageText object.

The second issue you mentioned above is still present, this was the one where the side effects could result in black screen or stack overflow errors.. working on that to be fixed a bit later once we've got a better way to handle this!

thanks

[Mintonist]

I think it is better to revert changes because there are no black screens before it.

[Mintonist]

Hi! @ajwfrost I test it again with AIR 51.2.1.4

Now with <runtimeInBackgroundThread>false</runtimeInBackgroundThread> it works (were changes revert?). But with <runtimeInBackgroundThread>true</runtimeInBackgroundThread> you need tap twice to textfield to write text. If you tap once - keyboard will appear but no text will be added to textfield and there will be no cursor.

So I see difference between 51.1.3 and 51.2.1.4 that were not mention in this issue.