Android - Crash with Listener EVENT_COME_TO_FOREGROUND and adding new ui::Widget

[AlexandreK38]

Hi!
I'm facing a strange bug and wanted to ask here if someone has faced it too, if it is expected because of how axmol is made or not as I'm not an expert.

What I do:
In the current scene I add a listener for EVENT_COME_TO_FOREGROUND and in it, I create a ui::Widget and add it to the scene.
On the UI I put a button that opens a link using Application::getInstance()->openURL("https://google.com"); and this causes the app to go to background.
When coming back on the app or using the back button, on some devices, it will crash. I suspect crashing or not depends if the java open gl/rendering is running and ready or not.
For example, on a Pixel 6 it is working without issue, but on a Samsung Tab S8 it will crash.
As side note I know Samsung mess up with activities and context after first launch depending how the app is started (see https://stackoverflow.com/questions/19545889/app-restarts-rather-than-resumes/23220151#23220151)

The solution is to delay the add by 0.1 second:

Director::getInstance()->getScheduler()->schedule([&](float /*dt*/){
          <add widget>
}, this, 0, 0, 0.1f, false, "delayed_widget");

I'm pretty sure this issue has created many crashes with different strange stacks for few years already.

[rh101]

Director::getInstance()->getScheduler()->schedule([&](float /dt/){

}, this, 0, 0, 0.1f, false, "delayed_widget");

Just out of curiosity, does it also work if a delay of 0.0f is used? This will ensure it runs on the next update cycle:

Director::getInstance()->getScheduler()->schedule([&](float /*dt*/){
          <add widget>
}, this, 0, 0, 0.0f, false, "delayed_widget");

or

scheduleOnce([](float) {
    ... 
}, 0.0f, "delayed_widget");

Strange things seem to happen in event handlers depending on what code you run in them. I just checked my own project, and noticed that I use the scheduleOnce method a lot with the 0.0f delay, some on purpose to ensure things run on the next update cycle, and others because I ran into issues that required me to use this same method to fix them.

[AlexandreK38]

Yeah it works too using a 0.f delay using

Director::getInstance()->getScheduler()->schedule([&](float /*dt*/){
          <add widget>
}, this, 0, 0, 0.0f, false, "delayed_widget");

So I'm not the only one :) Yeah I'm not sure why doing after the first mainLoop call is working and not the first one, but that's event handlers mistery

[rh101]

One day I'll dive into the event code and add trace logging calls to see how the whole system works. It's ultra low priority for me though, since it's easy to work around any issue with the scheduleOnce calls, but it will be interesting to find out why things work the way they do.

[rh101]

When coming back on the app or using the back button, on some devices, it will crash. I suspect crashing or not depends if the java open gl/rendering is running and ready or not.

That would happen if the EGL context is lost, so you would need to handle that scenario. If you want to verify if it is the cause of the crashes, then add a listener for the EVENT_RENDERER_RECREATED, and see if that event is triggered just before the crash occurs.

[AlexandreK38]

In fact this event is not called, it's just the Activities doing strange stuff and taking longer or so after launching the first time. Weird but it's Android as usual