Bug 397338 - No favorites displayed with empty config
Summary: No favorites displayed with empty config
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: master
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Marco Martin
URL: https://phabricator.kde.org/D14822
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-10 11:29 UTC by Fabian Vogt
Modified: 2018-08-22 12:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2018-08-10 11:29:13 UTC
Found by openQA: https://openqa.opensuse.org/tests/723601#step/desktop_mainmenu/2

It seems like the initial list of favorites is already empty when passed to portOldFavorites of the KaStatsFavoritesModel.

.config/plasma-org.kde.plasma.desktop-appletsrc contains:

[Containments][0][Applets][3][Configuration][General]
favorites=
favoritesPortedToKAstats=true
Comment 1 Fabian Vogt 2018-08-11 09:30:30 UTC
This is caused by the KAStatsFavoritesModel emitting favoritesChanged before the migration started.
Kickoff then writes that data back into the configuration file. Is that necessary?

Thread 1 "plasmashell" hit Breakpoint 1, KConfigGroup::writeEntry (this=this@entry=0x555555fbd240, key=key@entry=0x555555e97578 
"favorites", value=<QArrayData::shared_null+24> "", flags=flags@entry=...) at 
/usr/src/debug/kconfig-5.49.0git.20180808T183635~499edce-4.1.x86_64/src/core/kconfiggroup.cpp:873
873     {
#0  KConfigGroup::writeEntry (this=this@entry=0x555555fbd240, key=key@entry=0x555555e97578 "favorites", 
value=<QArrayData::shared_null+24> "", flags=flags@entry=...) at 
/usr/src/debug/kconfig-5.49.0git.20180808T183635~499edce-4.1.x86_64/src/core/kconfiggroup.cpp:873
#1  0x00007ffff2ea5081 in KConfigGroup::writeEntry (this=this@entry=0x555555fbd240, key=0x555555e97578 "favorites", value=..., 
flags=...) at /usr/src/debug/kconfig-5.49.0git.20180808T183635~499edce-4.1.x86_64/src/core/kconfiggroup.cpp:1080
#2  0x00007ffff2ea590f in KConfigGroup::writeEntry (this=0x555555fbd240, key=..., value=..., flags=...) at 
/usr/include/qt5/QtCore/qarraydata.h:206
#3  0x00005555555b14cc in ?? ()
#4  0x00005555555c380e in ?? ()
#5  0x00005555555c7aa1 in ?? ()
#6  0x00005555555c7c95 in ?? ()
#7  0x00007ffff56df13d in ?? () from /usr/lib64/libQt5Qml.so.5
#8  0x00007ffff564a0ad in ?? () from /usr/lib64/libQt5Qml.so.5
#9  0x00007ffff564b6e5 in ?? () from /usr/lib64/libQt5Qml.so.5
#10 0x00007ffff564c269 in QV4::QObjectMethod::callInternal(QV4::Value const*, QV4::Value const*, int) const () from 
/usr/lib64/libQt5Qml.so.5
#11 0x00007ffff5665fcb in QV4::Runtime::method_callProperty(QV4::ExecutionEngine*, QV4::Value*, int, QV4::Value*, int) () from 
/usr/lib64/libQt5Qml.so.5
#12 0x00007ffff5659a76 in ?? () from /usr/lib64/libQt5Qml.so.5
#13 0x00007ffff55ff1af in QV4::Script::run(QV4::Value const*) () from /usr/lib64/libQt5Qml.so.5
#14 0x00007ffff559b14a in QJSEngine::evaluate(QString const&, QString const&, int) () from /usr/lib64/libQt5Qml.so.5
#15 0x00005555555b797f in ?? ()
#16 0x000055555559e20f in ?? ()
#17 0x000055555559e790 in ?? ()
#18 0x000055555559ec79 in ?? ()
#19 0x00007ffff1e41cf0 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#20 0x00007ffff7473111 in KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus) () from 
/usr/lib64/libKF5Activities.so.5
Comment 2 Fabian Vogt 2018-08-11 16:22:15 UTC
I got it, I think.

There's a kickoffrc with a list of favorites in /etc/xdg, so obsolete_kickoffrc.js is ran to convert it.

The bt is actually just another symptom of the underlying cause: KConfig called fromdo desktop scripting can't save arrays.

Arrays in QJSEngine are apparently objects and get converted to QJSValue on the C++ side - which KConfigGroup can't handle. So it saves an empty value.

That caused the message of "KConfigGroup::writeEntry - unhandled type QJSValue".
Comment 3 Fabian Vogt 2018-08-13 12:54:35 UTC
The cause is that methods with a QVariant as a parameter type called from js always get a QJSValue as QVariant.

Even passing trivial types such as integers results in a QVariant with a QJSValue in it.

Fix is to use QJSValue as parameter directly and call param.toVariant().

I guess this needs to be done in quite some places...
Comment 4 Fabian Vogt 2018-08-14 10:02:24 UTC
https://phabricator.kde.org/D14822 fixes this for p-w, but other uses of QJSEngine (kwin?) might have the same issue.
Comment 5 Fabian Vogt 2018-08-22 12:20:52 UTC
Git commit 6e5c9e9b16666cea60f8d95f33dfd2664c7ea626 by Fabian Vogt.
Committed on 22/08/2018 at 12:19.
Pushed by fvogt into branch 'master'.

Use QJSValue as method parameter type for the scripting interface

Summary:
If a slot or Q_INVOKABLE has a QVariant as parameter and gets called
from a QJSEngine's script, it receives a QJSValue wrapped as QVariant.
To get a QVariant with the actual value wrapped, calling QJSValue::toVariant
is necessary.

I'm not entirely sure whether this is intentional behaviour of QJSEngine, but
even if it's a bug we'll have to workaround it.

Test Plan: I have favorites in kickoff again.

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14822

M  +10   -10   shell/scripting/applet.cpp
M  +5    -4    shell/scripting/applet.h
M  +2    -2    shell/scripting/configgroup.cpp
M  +2    -1    shell/scripting/configgroup.h
M  +1    -1    shell/scripting/scriptengine_v1.cpp

https://commits.kde.org/plasma-workspace/6e5c9e9b16666cea60f8d95f33dfd2664c7ea626