Submission checklist
Bug description
Noctalia's clipboard manager intermittently records a copied text entry in
its history, but the same text cannot be pasted into other applications using
Ctrl+V or the context-menu Paste action.
The source application is still open when this happens. Therefore, this is not
limited to copying from an application that has exited.
During one occurrence:
- The copied entry was visible in Noctalia's clipboard history.
- Noctalia IPC still returned non-empty stored clipboard text.
wl-paste --list-types reported that the live Wayland clipboard was empty.
- Pasting failed in multiple target applications.
This appears different from #3671. That issue caused the previous clipboard
content to be pasted until copying a second time. In this case, the live
Wayland selection becomes empty while Noctalia still retains the copied text
in its history.
The problem is intermittent, so I do not yet have fully deterministic
reproduction steps.
Steps to reproduce
- Enable Noctalia's clipboard manager.
- Enable
clipboard_keep_from_closed_apps.
- Run Noctalia under Niri.
- Copy text normally from an application.
- Keep the source application open.
- Occasionally, the new entry appears in Noctalia's clipboard history, but
Ctrl+V and the context-menu Paste action do not paste it.
- While the failure is present, run:
wl-paste --list-types
- Observe that it reports "Nothing is copied", even though Noctalia still has
the text in its history.
Expected behavior
Once Noctalia has successfully stored a copied text entry, the live Wayland
clipboard selection should remain available, or Noctalia should adopt the
stored data immediately if the original data source releases the selection.
The text should be pasteable even when the source application remains open.
Actual behavior
Noctalia's history contains the copied text, but the live Wayland selection is
sometimes empty. Ctrl+V and the context-menu Paste action consequently do
nothing.
A later clipboard operation may make copying and pasting work again, which
makes the problem appear intermittent.
Logs / error output
$ wl-paste --list-types
Nothing is copied
$ noctalia msg clipboard-text | wc -c
71
The exact byte count varies with the copied text, but it is non-zero while
wl-paste reports that the live selection is empty.
No corresponding error was found in the journal.
Noctalia version
Observed on v5.0.0 (g50f0f0950); the relevant code path is still present in e41c994. Currently testing e41c994 with a local candidate patch.
Compositor
Niri
Distribution
Arch-based
Environment information
Installation method: ArchLinuxCN noctalia-git
Current test build: 5.0.0.r5069.ge41c99439 with a local candidate patch
Compositor: Niri 26.04
GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]
Kernel driver: i915
Kernel: 7.1.5-1-cachyos
Clipboard enabled: true
clipboard_keep_from_closed_apps: true
Additional context
I found a possible starvation path in the current main branch:
- ClipboardService::handleSelection(nullptr) sets
m_pendingOrphanAdopt = true.
- The pending adoption is only processed by
ClipboardService::dispatchPollEvents().
- ClipboardPollSource does not advertise a timeout.
- The main loop only dispatches a PollSource when one of its file
descriptors is ready or its timeout expires.
If the selection becomes NULL while the clipboard service has no active read
or write file descriptor, ClipboardPollSource may never be dispatched and the
pending adoption may remain queued indefinitely.
I am testing a candidate fix that makes ClipboardPollSource advertise a 0 ms
timeout while orphan adoption is pending, returning to -1 after it is
processed. The candidate includes a regression test, and all 68 tests pass.
I have not yet concluded that this explains every paste failure, but it appears
to explain the observed state where Noctalia retains the text while the live
Wayland selection is empty. I can provide the patch or open a PR if this
analysis is correct.
Submission checklist
Bug description
Noctalia's clipboard manager intermittently records a copied text entry in
its history, but the same text cannot be pasted into other applications using
Ctrl+V or the context-menu Paste action.
The source application is still open when this happens. Therefore, this is not
limited to copying from an application that has exited.
During one occurrence:
wl-paste --list-typesreported that the live Wayland clipboard was empty.This appears different from #3671. That issue caused the previous clipboard
content to be pasted until copying a second time. In this case, the live
Wayland selection becomes empty while Noctalia still retains the copied text
in its history.
The problem is intermittent, so I do not yet have fully deterministic
reproduction steps.
Steps to reproduce
clipboard_keep_from_closed_apps.Ctrl+V and the context-menu Paste action do not paste it.
wl-paste --list-typesthe text in its history.
Expected behavior
Once Noctalia has successfully stored a copied text entry, the live Wayland
clipboard selection should remain available, or Noctalia should adopt the
stored data immediately if the original data source releases the selection.
The text should be pasteable even when the source application remains open.
Actual behavior
Noctalia's history contains the copied text, but the live Wayland selection is
sometimes empty. Ctrl+V and the context-menu Paste action consequently do
nothing.
A later clipboard operation may make copying and pasting work again, which
makes the problem appear intermittent.
Logs / error output
Noctalia version
Observed on v5.0.0 (g50f0f0950); the relevant code path is still present in e41c994. Currently testing e41c994 with a local candidate patch.
Compositor
Niri
Distribution
Arch-based
Environment information
Additional context
I found a possible starvation path in the current main branch:
m_pendingOrphanAdopt = true.ClipboardService::dispatchPollEvents().descriptors is ready or its timeout expires.
If the selection becomes NULL while the clipboard service has no active read
or write file descriptor, ClipboardPollSource may never be dispatched and the
pending adoption may remain queued indefinitely.
I am testing a candidate fix that makes ClipboardPollSource advertise a 0 ms
timeout while orphan adoption is pending, returning to -1 after it is
processed. The candidate includes a regression test, and all 68 tests pass.
I have not yet concluded that this explains every paste failure, but it appears
to explain the observed state where Noctalia retains the text while the live
Wayland selection is empty. I can provide the patch or open a PR if this
analysis is correct.