Do you have a good way to test this without manually editing the app code to skip this step? 😅

Not really unfortunately ... I did tweak the code, you could also use a different version of the app without the flag (before the new onboarding like 2025.8.7)

Why is there an up arrow if we want the user to choose before continuing?

Well we had a long disussion with @bgoncal about this screen being optional, he made it optional on iOS with a cross. If the user close it with the cross it's going to be shown again when opening the app again next time. At first I wanted to make this mandatory but I get the point that a user might just want to do something quick in the app and doesn't have the time to read.

Easiest way I found to test: onboard using https url which doesn't set the preference, then change it to http afterwards.

• When temporarily skipping the screen, I can use the up button on screen and this will load the dashboard. However, using the system back button doesn't do that and instead I end up with a blank screen that does nothing.

• If the app is paused and resumed with the connection security level screen visible, you still get an overlay for the frontend timeout ("Could not connect to Home Assistant"). This can happen with the user hiding/resuming the app, but also if you get a permission dialog for 'most secure' > deny and wait a bit.

Well we had a long disussion with @bgoncal about this screen being optional, he made it optional on iOS with a cross. If the user close it with the cross it's going to be shown again when opening the app again next time.

OK, I see how not forcing but showing it every time until a choice is made is nice. However, maybe we should also show a close/cross button in this situation to make that more obvious? It's not uncommon for Android apps to have that as the first icon in the top app bar. (I'm also thinking of a redesigned frontend timeout screen, where you want a close instead of up button.)

I'm also thinking of a redesigned frontend timeout screen, where you want a close instead of up button.

What do you mean?

I'm going to make it a cross instead, to make it simpler is it fine for you to also use a cross when the fragment is opened from the settings too?

I'm also thinking of a redesigned frontend timeout screen, where you want a close instead of up button.

What do you mean?

My assumption was that you were working on replacing the frontend timeout pop-up with a full screen dialog that guides the user more on how to fix it like iOS / the onboarding connection error screen? In that one I'd expect a top app bar with a refresh or close icon in the top left.

I'm going to make it a cross instead, to make it simpler is it fine for you to also use a cross when the fragment is opened from the settings too?

Well in the settings screen an up arrow makes more sense 😅 not a dialog but a normal full screen in that case

I'm also thinking of a redesigned frontend timeout screen, where you want a close instead of up button.

What do you mean?

My assumption was that you were working on replacing the frontend timeout pop-up with a full screen dialog that guides the user more on how to fix it like iOS / the onboarding connection error screen? In that one I'd expect a top app bar with a refresh or close icon in the top left.

I'm going to do this once we drop the WebViewActivity not before.

I'm going to make it a cross instead, to make it simpler is it fine for you to also use a cross when the fragment is opened from the settings too?

Well in the settings screen an up arrow makes more sense 😅 not a dialog but a normal full screen in that case

🥲 I'm going to handle both cases on Wednesday.

Done 👍🏻

If the app is paused and resumed with the connection security level screen visible, you still get an overlay for the frontend timeout ("Could not connect to Home Assistant"). This can happen with the user hiding/resuming the app, but also if you get a permission dialog for 'most secure' > deny and wait a bit.

This still hasn't been addressed.

If the app is paused and resumed with the connection security level screen visible, you still get an overlay for the frontend timeout ("Could not connect to Home Assistant"). This can happen with the user hiding/resuming the app, but also if you get a permission dialog for 'most secure' > deny and wait a bit.

This still hasn't been addressed.

I thought I did by checking if a fragment is displayed when calling wait for connection. But maybe I'm wrong and the fragment is not displayed anymore.

If the app is paused and resumed with the connection security level screen visible, you still get an overlay for the frontend timeout ("Could not connect to Home Assistant"). This can happen with the user hiding/resuming the app, but also if you get a permission dialog for 'most secure' > deny and wait a bit.

This still hasn't been addressed.

I thought I did by checking if a fragment is displayed when calling wait for connection. But maybe I'm wrong and the fragment is not displayed anymore.

@jpelgrom I'm curious about how to reproducing it, because I've added some logs and I can see that

• When opening the app for the first time we don't waitForConnection because we don't have the loaded URL yet, then we set the URL but we don't call waitForConnection since we show the fragment.
• When putting on background and then foreground waitForConnection is called but it doesn't do anything since there is a fragment being displayed so it simply continue.

@jpelgrom I'm curious about how to reproducing it, because I've added some logs and I can see that

* When opening the app for the first time we don't waitForConnection because we don't have the loaded URL yet, then we set the URL but we don't call waitForConnection since we show the fragment.

* When putting on background and then foreground waitForConnection is called but it doesn't do anything since there is a fragment being displayed so it simply continue.

I've just tried reproducing it again and I'm also unable to with the latest commit on this branch. Maybe I broke something with a manual edit or it was fixed in a later commit. Sorry to keep you waiting, in case this turned out to be a real issue we'll surely encounter it again after merging.