Regression: The DnD dialog closes when interacting with it too fast

[WildPenguin]

Hi,

I often use the DnD dialog (I need to use it several times a day to mute everything, for 1-9 hours or (rarely) indefinitely, on random times I can not know beforehand, such as unscheduled meetings, lectures etc.). As such, I know the dialog by heart and react to it really fast, in (approx.) sub-½-second timeframe once it has appeared (or, rather, begun to appear in this case).

The problem is that after some of the recent updates, the dialog is unresponsive while the animation has not finished. The animation actually takes a really long time to finish, somewhere around 2-3 seconds!!! (I haven’t taken the time, but it really feels like a really long time).

To make things worse, it is not only unresponsive, but the whole dialog closes on the user if any of the UI elements is tapped too soon!!! I was pulling my hair out several times, re-opening the dialog about seven times and swearing, why it is closing instead of adding time when tapping “+”.

It is possible most / many users don’t face the issue, since they don’t use the dialog that often and actually need to read/glimpse trough all the elements. But one who is accustomed to it, will be in a seeming “auto-close limbo/loop”.

Anyone seen this issue, and any known workarounds?

Or, is something else (the launcher?) affecting the behavior of dialogs / UI? I have changed my launcher recently, too.

Steps to reproduce:

1. Open the top-down menu
2. Tap on “Do not disturb”
3. Quickly tap on any of the elements, such as “+”, as if you know their position by heart and don’t need to read the whole dialog before reacting. (Memorize the position of this element by repeatedly opening the dialog before actually trying to reproduce).

Observed results:

The dialog closes if the user taps it before the animation completely stops.

Expected results:
The dialog should react to user input, if it has started to appear. It should never autoclose on the user.

Alternatively, the UI should just not-react instead of closing the dialog, but the first option is much more preferred.

Additionally, the animation should be faster (<500ms). Function over form would be much more preferred in this case, the “fluidness” of the animation has gone way overboard in this case.

More info
This is a regression, as on earlier versions, the dialog worked correctly.

[Incanus]

Welcome to the Fairphone community.

Your observation could be related to this.

Sudden slow response

Some days ago my Fairphone 4 suddenly slowed down. The response to opening and closing apps, for example, is clearly slower than before. Then again, for example typing SMS doesn’t seem to be slower. It looks/feels as if there was an adjustable response time and it would have been set long. But I can’t find such setting. Or when a computer is processing too much stuff at the time and goes slow. I have rebooted the phone a couple of times but it doesn’t help. Does someone have the same issue or …

[WildPenguin]

Hi,

Thanks Incanus for your reply.

I though my post was more appropriate in the development section as this is a clear regression caused by an update. But it’s fine it’s in the help section, too.

That thread is a bit sad in that it seems to have replies from users facing multiple unrelated issues. The animation speed (and the fact the setting doesn’t stick) and general unresponsiveness of the phone are separate issues.

I believe it is possible the dialogs have always worked such that they are “unusable” during any animation, but I haven’t noticed it as the animation was faster. But reducing the animation speed should not be required to “work around” the issue, the dialog should never auto-close the way I describe. But that may be an upstream Android issue.

Enabling developer options is not an acceptable solution, as it disables many (all?) NFC payment applications.

So I consider this issue as unsolvable, hoping a future firmware upgrade will fix the underlying regression (and possibly the underlying mechanism I’ve described in my post, in a more robust way).

[yvmuell]

@WildPenguin

Enabling developer options is not an acceptable solution, as it disables many (all?) NFC payment applications

this has zero influence and you can just disable once you checked the settings.

Edit: the forum is no contact to support to report bugs, thus please contact Fairphone to report this.

Edit2: the development section is for user who develop something not to report Software issues

[Furdiburd]

Enabling developer options does not disable most (99%) of banking apps ect.

The think you confused it with probably is unlocking the bootloader

[eelco_de_v]

I’m seeing the same issue when switching the WiFi on/off via the top-down menu.

Even a few milliseconds after it appears to have finished the animation it still doesn’t pick up the action. And annoyingly, closes the menu without having turned the WiFi on/off.

Similar thing happens when closing applications via a swipe on the open application overview. It plays the close app animation, but doesn’t actually close it, unless you watch the full second to finish the animation. Pretty sure it used to work fine at high speed.

Also sounds related to the other bug I started seeing:

App Search on Fairphone 4 opens another App

This problem is not unique to the Signal app. It also applies to the “Untis Mobile” app, for example. The funny thing is that sometimes the right app opens, but the wrong one opens again the next time I try. Incidentally, the logo is different because you can set this in the Signal settings. Here is a new link to the video

[eelco_de_v]

Also noticed the reverse. The homescreen icons stay unresponsive for seconds after closing the top down menu (by clicking the home button - circle icon) and clicking the visible icons before the top menu has 100% retracted.
Again, I suspect this relates to a recent Fairphone firmware update (FP4.TP2I.C.0121.20240626).