Bug 474579 - Initial view item's opacity is set to 0
Summary: Initial view item's opacity is set to 0
Status: RESOLVED UPSTREAM
Alias: None
Product: Elisa
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Matthieu Gallien
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2023-09-15 22:24 UTC by Jack Hill
Modified: 2023-10-05 18:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Hill 2023-09-15 22:24:44 UTC
SUMMARY
Debugging shows that the initial item pushed to browseStackView has an opacity of 0.

STEPS TO REPRODUCE
1. Launch Elisa
2. Open a view from sidebar

OBSERVED RESULT
Initially a blank view. After clicking an item from the sidebar, the view opens just fine.

EXPECTED RESULT
Initial view should not be blank

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20230911
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.10
Kernel Version: 6.5.2-1-default (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION
Comment 1 Jack Hill 2023-09-15 22:47:43 UTC
possibly only happens when a view isn't embedded into the sidebar
Comment 2 Jack Hill 2023-09-17 09:45:55 UTC
Qt version is 6.5.2 from openSUSE repos
Comment 3 Nate Graham 2023-09-19 19:55:09 UTC
Is this with a released version, or a git master version built with Qt 6?
Comment 4 Jack Hill 2023-09-28 21:59:24 UTC
This is git master with Qt6, and it's caused by browseStackView's replaceEnter transition -- commenting out this transition fixes it.

It might be a Qt bug since using StackView.push() or setting the replace operation to StackView.Immediate doesn't help.
Comment 5 Nate Graham 2023-09-29 17:49:53 UTC
I actually can't reproduce that issue right now with current git master, but if I apply https://invent.kde.org/multimedia/elisa/-/merge_requests/496, it comes back.
Comment 6 Nate Graham 2023-09-29 19:36:20 UTC
Never mind, now it's fixed with that MR as well.
Comment 7 Jack Hill 2023-09-29 19:38:33 UTC
This is almost certainly an upstream bug since I can reproduce it with a fresh pure QML project.

Btw did you apply the patch I suggested in the MR? Because that disables the transition so the issue is not noticeable. If you didn't then I guess it must've been fixed by magic
Comment 8 Nate Graham 2023-09-29 19:40:35 UTC
Never mind, I had actually failed to apply the MR correctly and was building master. it's still broken for me with that MR.

You could well be right that it's a Qt bug, but then we need to either fix it upstream, or work around it in Elisa.
Comment 9 Jack Hill 2023-10-02 10:35:09 UTC
See https://bugreports.qt.io/browse/QTBUG-117720
Comment 10 Nate Graham 2023-10-05 18:37:42 UTC
Git commit 3d63c4fcf1de7a551322ac234755fca3c1f99cc6 by Nate Graham, on behalf of Jack Hill.
Committed on 05/10/2023 at 20:32.
Pushed by ngraham into branch 'master'.

ContentView: force ReplaceTransition when replacing the stack

Normally Qt will use the Immediate transition if the stack is empty, but
this behaviour is bugged when using OpacityAnimator. Instead of setting
properties to their `to` value, they are set to their `from` value
(these are defined in the Transition). This results in the initial view
item having an opacity of 0. The workaround is to force a
ReplaceTransition.

See https://bugreports.qt.io/browse/QTBUG-117720

M  +3    -1    src/qml/ContentView.qml

https://invent.kde.org/multimedia/elisa/-/commit/3d63c4fcf1de7a551322ac234755fca3c1f99cc6