https://bugs.kde.org/show_bug.cgi?id=525820
Bug ID: 525820
Summary: Creating an event silently fails - The cause is a QML
TypeError at IncidenceEditorPage.qml:94
Classification: Applications
Product: Merkuro
Version First 26.08.1
Reported In:
Platform: CachyOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Product: Merkuro
Component: General
Version: 26.08.1
Severity: normal
SUMMARY
Creating an event silently fails: the Add button does nothing and the dialog
stays open. The cause is a QML TypeError at IncidenceEditorPage.qml:94 which
aborts the onAccepted handler before it can either save the incidence or close
the dialog.
STEPS TO REPRODUCE
1. Have at least one writable calendar, and no lastUsedEventCollection set in
merkuro.calendarrc (the default state).
2. Create a new event. Fill in a title. Do not touch the Calendar dropdown.
3. Click Add.
OBSERVED RESULT
No event is created. The dialog does not close. Nothing is shown in the UI.
Each click logs one line:
merkuro-calendar[2574]:
qrc:/qt/qml/org/kde/merkuro/calendar/qml/Dialogs/IncidenceEditorPage.qml:94:
TypeError: Cannot read property 'currentValue' of undefined
EXPECTED RESULT
The event is created in the calendar shown in the dropdown, and the dialog
closes.
SOFTWARE/OS VERSIONS
Merkuro 26.08.1
Akonadi 26.08.1
KDE Frameworks 6.30.0
Qt 6.11.2
KDE Plasma 6.7.5
Linux/KDE Plasma: CachyOS (Arch), kernel 7.2.5
Calendars come from an akonadi_davgroupware_resource against a CalDAV server.
Reads, syncs and writes to that server all work.
ADDITIONAL INFORMATION
Line numbers below are from tag v26.08.1 and are unchanged in master as of
2026-09-16.
src/calendar/qml/Dialogs/IncidenceEditorPage.qml, onAccepted handler of the
DialogButtonBox:
onAccepted: {
if (root.editMode) {
Calendar.CalendarManager.editIncidence(root.incidenceWrapper);
} else if (root.validDates) {
if (root.incidenceWrapper.collectionId < 0) {
root.incidenceWrapper.collectionId =
editorLoader.item.calendarCombo.currentValue; // line 94
}
if (root.incidenceWrapper.collectionId < 0) {
root.incidenceWrapper.collectionId =
editorLoader.item.calendarCombo.defaultCollectionId; // line 97
}
...
Calendar.CalendarManager.addIncidence(root.incidenceWrapper); //
line 107
}
root.cancel(); //
line 109
}
calendarCombo (line 246) is an id on the Akonadi.FormCollectionComboBox inside
the editorLoader sourceComponent. QML ids are not properties of the component
root, and no property alias exposes it, so editorLoader.item.calendarCombo is
undefined unconditionally. Whenever line 94 is reached it throws, and the
exception aborts the handler before both addIncidence() on line 107 and
root.cancel() on line 109. That accounts for both halves of the symptom: no
event is saved, and the dialog does not close.
Lines 94 and 97 are therefore dead code that can only ever throw.
Line 94 is reached only when incidenceWrapper.collectionId < 0, so the trigger
is an incidence arriving at the editor with no collection assigned.
Note that collectionId is -1, not 0 in the failing case, so the Add button's
enabled
condition on line 84
enabled: root.validDates && root.incidenceWrapper.summary &&
root.incidenceWrapper.collectionId
is True and the button stays clickable.
WHY THE COLLECTION IS UNASSIGNED
This part is less certain than the above and is offered as a starting point.
The only place the editor assigns the collection is calendarCombo's
onCurrentIndexChanged, line 268:
onCurrentIndexChanged: {
if (calendarCombo.model.rowCount() === 0) {
return;
}
let selectedModelIndex = calendarCombo.model.index(currentIndex, 0);
let selectedCollection = calendarCombo.model.data(selectedModelIndex,
Akonadi.EntityTreeModel.CollectionRole);
root.incidenceWrapper.setCollection(selectedCollection)
}
FormCollectionComboBox declares currentIndex: 0 outright, and
CollectionComboBoxModel fills mDefaultCollectionId from row 0 on the first
rowsInserted when no default was set, then calls setCurrentIndex(0). If the
combo's currentIndex is already 0 by the time the model populates,
onCurrentIndexChanged either never fires or fires while rowCount() is still 0
and takes the early return. Either way setCollection is never called,
collectionId stays -1, and the first Add click lands on line 94.
This matches the behaviour: the dropdown visibly shows a calendar name, but
that calendar was never assigned to the incidence.
Consistent with this, changing the dropdown to a different calendar and back
makes Add work immediately, because that forces currentIndex to change with a
populated model.
WORKAROUNDS
In the event dialog, open the Calendar dropdown and pick an entry other than
the one already displayed. Add then works.
Persistent, with Merkuro closed:
kwriteconfig6 --file merkuro.calendarrc --group Editor --key
lastUsedEventCollection <collectionId>
This only helps if the chosen collection is not the first row of the filtered
combo, since otherwise currentIndex still never changes.
Merkuro does not write lastUsedEventCollection itself even after an event has
been added successfully through the dropdown workaround, despite Config.save()
on line 105. That may be worth a look separately.
SUGGESTED FIX
Two separate things:
1. Expose the combo, for example with property alias calendarCombo:
calendarCombo on the sourceComponent root, so the fallbacks on lines 94 and
97 can actually run instead of throwing.
2. Make the initial collection assignment not depend on currentIndex changing.
Assigning from the model once it is populated, or handling
FormCollectionComboBox's userSelectedCollection signal alongside an explicit
initial assignment, would avoid the race entirely.
POSSIBLY RELATED
Bug 521734 may be the same defect on a different build. The collection picker
is described there as "evaluating a binding that reads the collection's color
before its currentIndex/currentCollection is actually set to something valid",
which is the same uninitialized-index state, surfacing as an assertion in
ColorProxyModel::data() instead of a QML TypeError.
Bug 512918 reports the same user-visible symptom in Bug 512918 comment 2 ("New
event
dialogs open but don't save entries after clicking Add"), though that reporter
also has task creation crashing outright, so it may be a different underlying
problem.
--
You are receiving this mail because:
You are watching all bug changes.
