Created attachment 141526 [details] Mobile controls seen inappropriately Strange bug; just what the title says. If I open Discover by clicking on the Notifier System Tray item while in a Wayland session, mobile controls appear on the Updates page. They do not appear if accessing the Updates page from any other way: - Launching the app and going to the Updates page manually in a Wayland session - Launching the app and going to the Updates page manually in an X11 session - Launching the app from the Notifier System Tray item in an X11 session
Correction: This happens on X11 too.
can you check if you have QT_QUICK_CONTROLS_MOBILE set?
I don't. If I manually set it and launch Discover it opens in dedicated mobile mode, which is different from what I see in this bug. With this bug, I just see the mobile controls on the Updates page in addition to the desktop controls; everything else is normal.
Do you use systemd startup? Maybe it's using different env vars because it comes from the notifier process? 🤔 Also I tried and cannot reproduce. Would you be able to poke a bit the Loader.active property in the actionButtons Loader at the bottom of Page.qml? It's the one that decides if it should be shown.
Yes, I'm using systemd startup. I can poke.
Created attachment 141664 [details] In Kirigami Gallery too I'm actually seeing the same thing in Kirigami gallery now!
Does not seem to be Discover-specific; moving to Kirigami.
Managed to reproduce it and fix it upstream Qt. https://codereview.qt-project.org/c/qt/qtdeclarative/+/372022 Workarounds would be to either mark it a synchronous or add a `visible: active`. Both aren't ideal but better than the status quo.
Wow, great sleuthing, Aleix!
I think making it synchronous for now would probably make sense until the fix trickles back to us. What do you think, Arjen?
Another alternative would be to have an: onItemChanged: if (!active) item.destroy() This would keep it async and continue to work as the fix gets merged.
The more fundamental problem is that the action button loader gets activated while it should simply never be active in desktop mode. This is due to how the globalToolBarStyle property is handled: If it is not explicitly set to toolbar, we always activate the ActionButton. This leads to problems because there is a period of time where the Loader is created and its active property being evaluated while the global toolbar style is still set to the default. In my opinion, the more fundamental fix should be to either have an "unknown" style as default toolbar style, or somehow make sure the global toolbar style property is initialzed before anything that depends on it.
We are getting a lot of user complaints about this. Raising to VHI.
I have not seen this issue since I fixed it in Qt. We can consider reverting the asynchronous Loaders patch if you think distros aren't going to use our Qt patches. It's a bit unfortunate though. Maybe we can somehow detect it at build time? FWIW, there aren't duplicates here or anything, which complaints are you talking about?
(In reply to Aleix Pol from comment #14) > FWIW, there aren't duplicates here or anything, which complaints are you > talking about? Users on social media. I guess they're using distros without the KDE patch collection Sadly I am too; Fedora hasn't shipped it yet. Oh well, since it's fixed in Qt and a fix is available, I guess you're right and we can close this and yell at distros that aren't shipping the fix yet. :)
*** Bug 459114 has been marked as a duplicate of this bug. ***
*** Bug 464779 has been marked as a duplicate of this bug. ***