Just refuses to copy the url in Firefox. It was working earlier I'm sure, well it was working on Gnome. I've downloaded the Firefox Nightly and that has the same issues. Copies content in Firefox and everywhere else. Is the clipboard manager a default or did I install that? Operating System: Rocky Linux 9.2 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.3 Kernel Version: 5.14.0-284.11.1.el9_2.x86_64 (64-bit) Graphics Platform: Wayland Processors: 64 × AMD EPYC 7551P 32-Core Processor Memory: 125.2 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Supermicro Product Name: Super Server System Version: 0123456789
Can confirm on Arch Linux running Plasma 5.27.6 when Firefox 114.0.2 runs natively on Wayland. Can't confirm when Firefox runs on Xwayland instead. Also can't copy urls via "Copy link" option from the context menu.
This has disappeared after a reinstall.
It doesn't seem limited to the URL bar, clicking the Copy button in the passwords page as well as the Copy button when taking a screenshot in the browser also do not work. This is with Plasma 5.27.6 and Firefox 115.0.1 on Wayland and Arch Linux, although it has been like this for quite a long while (to the point where copying the URL, pasting it into whatever text field I can find in the site and then copying out of that is almost muscle memory now). On Sway this bug does not appear. Also, I noticed that when there is something on the clipboard already attempting to copy the URL clears the clipboard, although Klipper/the clipboard manager doesn't notice. In addition, I also tried running a nested KWin Wayland session on top of Plasma X11 by running `export $(dbus-launch); kwin_wayland --xwayland --x11-display :0`, then running `WAYLAND_DISPLAY=wayland-0 MOZ_ENABLE_WAYLAND=1 firefox` to start Firefox in the nested KWin session, followed by running `WAYLAND_DISPLAY=wayland-0 QT_QPA_PLATFORM=wayland kate` to run Kate in Wayland mode in that same KWin session, and finally trying to copy from Firefox's URL bar to Kate, which also did not work. So, since as I understand it Klipper would not be running in that nested KWin Wayland session I'm also moving the bug to KWin instead of the generic KDE category it is in at the moment.
Also, to be clear I am using Firefox in native Wayland mode, if it is running through XWayland the bug indeed does not appear.
I am also seeing the same behavior as Prajna, on essentially the same setup (Arch Linux). I believe it started four or five months ago, and I've been working around it by first copy/pasting URLs from the URL bar into the separate search bar that you can optionally have in Firefox. From there I can copy/paste it into other applications. There is one person on the Arch forums who says they had some trouble with this that was fixed with a system update in April, but that hasn't been the case for me: https://bbs.archlinux.org/viewtopic.php?id=285094
Should I report this to Mozilla? It's a right pest and it is intermittent, I have no idea what it triggering it.
> Should I report this to Mozilla? After you asked, I searched Mozilla's Bugzilla for related issues. I've just found an open bug at Mozilla that describes a workaround. I've tested this workaround, and it seems to work for me. https://bugzilla.mozilla.org/show_bug.cgi?id=1791417 The workaround: Open System Settings -> Workspace Behavior -> General Behavior -> Middle Click: Paste Selected Text Make sure that "Middle Click: Paste Selected Text" is checked. In other words, make sure that it is enabled. Restart your system. On my system, that setting was disabled. After enabling it and restarting, I was able to copy/paste between the Firefox URL bar and other applications. "Copy Link" also seems to work properly."
(In reply to Andrew Todd from comment #7) > > Should I report this to Mozilla? > > After you asked, I searched Mozilla's Bugzilla for related issues. > > I've just found an open bug at Mozilla that describes a workaround. I've > tested this workaround, and it seems to work for me. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1791417 > > The workaround: > > Open System Settings -> Workspace Behavior -> General Behavior -> Middle > Click: Paste Selected Text > > Make sure that "Middle Click: Paste Selected Text" is checked. In other > words, make sure that it is enabled. > > Restart your system. > I've set it as you suggest. Seems like an unlikely fix as the issue is intermittent.
The issue doesn't seem to be intermittent, at least for me it's surely consistently a problem with the address bar, and seems like others have the same issue. The oddity which may make it appear intermittent is Firefox internally still making a copy, so pasting within the same browser session is fine, but the native clipboard doesn't change. Couldn't reproduce the screenshot problem on Plasma 5.27.4 with Firefox 116.0.2, although earlier I've had issues with that, but I believe it could have been a different issue as seemingly with some actions the screenshot disappeared from the clipboard, and some targets required pasting twice to process the image, so I'd classify that a different kind of beast. The issue seems to be with zwp_primary_selection_device_manager_v1 not being exposed when middle click pasting is disabled, but I don't believe it to be a KDE problem, and I'd argue that accommodating programs expecting primary selection emulation to just work would be counterproductive. Optimally programs would check for indication of support and would modify their behavior accordingly, so hopefully the hardcoded middle click pasting would slowly die out in favor of optional support.
(In reply to Pedro V from comment #9) > > The issue seems to be with zwp_primary_selection_device_manager_v1 not being > exposed when middle click pasting is disabled, but I don't believe it to be > a KDE problem, and I'd argue that accommodating programs expecting primary > selection emulation to just work would be counterproductive. Optimally > programs would check for indication of support and would modify their > behavior accordingly, so hopefully the hardcoded middle click pasting would > slowly die out in favor of optional support. I think that's at least the cause of the issue, where it is, is another matter. Firefox seems to use gtk to provide the protocol implementation, so I wonder if gtk apps are concerned too. gtk seems to special case when the protocol is missing and implementing it within the app, bypassing our setting and making it not work with other apps: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/wayland/gdkseat-wayland.c#L4291 This might part of the root issue.
This is also an issue with Thunderbird. With MOZ_ENABLE_WAYLAND=1 and middle-click-to-paste disabled, right clicking any link and clicking "Copy Link Location" results in no data available to paste. But Ctrl+C or selecting any text and right click + Copy works. Comparing the debug console (qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole) with enabling/disabling the middle click paste, when enabled the bottom area will say "*Primary Selection* zwp_primary_selection_source_v1 of", and with disabled there is nothing. > https://bugzilla.mozilla.org/show_bug.cgi?id=1791417 Looks like now that MOZ_ENABLE_WAYLAND=1 is the default, this is getting attention in that mozilla issue
https://bugzilla.mozilla.org/show_bug.cgi?id=1791417 got updated, theoretically we are just waiting for https://phabricator.services.mozilla.com/D198141 to get merged assuming it's simple enough not to break anything. Going forward, I'm still not sure there will be much to track here. The assumption that primary selection is always functional on Linux just needs to go away, KDE isn't doing anything wrong by letting the user opt out of a functionality that's quite descriptively called "X primary selection emulation". Firefox also has the oddity that it uses the regular clipboard first, then trashes it by attempting to use primary selection, even though the selection didn't actually change, which is why the copying issue was limited to the weird URL handling logic, therefore I wouldn't really expect this to reappear (often) even if primary selection keeps being used incorrectly.
The recently released Firefox 122.0 stopped using primary selection when support for it isn't advertised, therefore the issue is fixed there. Unfortunately the recently released Thunderbird 115.7.0 didn't get this fix, therefore that's still affected.
(In reply to Pedro V from comment #13) > The recently released Firefox 122.0 stopped using primary selection when > support for it isn't advertised, therefore the issue is fixed there. > Unfortunately the recently released Thunderbird 115.7.0 didn't get this fix, > therefore that's still affected. At some point in the last week I tried the thunderbird nightly build to see if it was fixed and it seemed to be. I noticed in the upstream bug they added a bunch of release tags for firefox but ignored thunderbird. I wanted to comment on it but they locked the thread after it was "fixed" so I'm not sure how to let them know. Not sure why the lock, that's like a meta-bug.