1791417 - [KDE Wayland async clipboard] Can't copy from address bar and paste into other apps if "Middle Click: Paste Selected Text" is disabled in KDE settings>Workspace>General. Copying from websites still works: Why does the address bar behave differently?

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Grayson Guarino]

Steps to reproduce:

1. Select the URL in Firefox address bar
2. Press Ctrl+C or choose "Copy" in context menu
3. Try pasting in another app

This issue is confirmed to occur on both Mir and Weston.
Mir bug report here https://github.com/MirServer/mir/issues/2583

Actual results:

I can copy/paste URLs within Firefox, but the contents of the clipboard are not accessible from other applications.

Expected results:

Links should be pasteable into other applications.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sophie Winter]

My testing has revealed that the problem occurs when the primary selection protocol (zwp_primary_selection_device_manager_v1) is not implemented, which explains why it only shows up on some compositors. Adding a stub implementation of the protocol to Mir makes this bug go away. Primary selection should not be required for copy/paste, and is not required for copy/paste in firefox in any context except copying out of the address bar.

Comment 3

[Will]

I have the same thing with KDE Plasma under Wayland. A couple of notes in case it's useful, but it sounds like the root cause is already known.

• It's still present in 110.0
• Paste into firefox is unaffected
• Copying from page content is unaffected
• The bug is present whether the window protocol is wayland or xwayland

Comment 4

[mkoushan]

Same issue in KDE Plasma under Wayland in Arch. Also if I copy something from firefox URL bar it will clear/replace clipboard with empty string or something. This also happens with firefox development edition 111.0b7 (64-bit).
I found a way to copy URL of website:
1.Bookmark the current website
2.Edit the bookmark and copy the url from there
it will work this way.

Comment 5

[Cody]

Attachment: Wayland info

I am also hitting this on Fedora 37 KDE with Wayland.
When copying the URL from the URL bar, it will ONLY paste in Firefox. When copying from a webpage, it will paste in any other application.

From URL bar -> Firefox : Works.
From URL bar -> Other applications : Does not work.
From Webpage -> Other application & Firefox : Works.

Firefox 111.0.1
Fedora 37
KDE 5.27.3
KDE Framework 5.104.0
QT 5.15.8
Kernel 6.2.8-200.fc37
Graphics: NVIDIA GeForce RTX 2070 Super with Max-Q
Graphics Driver: 530.41.03

Wayland:
```

Comment 6

[Cody]

I am also hitting this on Fedora 37 KDE with Wayland.
When copying the URL from the URL bar, it will ONLY paste in Firefox. When copying from a webpage, it will paste in any other application.

From URL bar -> Firefox : Works.
From URL bar -> Other applications : Does not work.
From Webpage -> Other application & Firefox : Works.

Firefox 111.0.1
Fedora 37
KDE 5.27.3
KDE Framework 5.104.0
QT 5.15.8
Kernel 6.2.8-200.fc37
Graphics: NVIDIA GeForce RTX 2070 Super with Max-Q
Graphics Driver: 530.41.03

Comment 7

[Dragoon Aethis]

How to reproduce this on a fairly fresh KDE 5.27 distro, as of today:

• Run a Plasma Wayland session
• Run MOZ_ENABLE_WAYLAND=1 firefox
• You can copy-paste stuff from Firefox into other software (like a text editor, etc)
• In KDE System Settings, uncheck Workspace Behavior -> General Behavior -> Middle Click: Paste Selected Text
• Log out and restart Firefox in Wayland mode.
• Copying from Firefox into other apps no longer works.

SOFTWARE/OS VERSIONS

• Arch Linux (up-to-date as of 2022-04-17)
• Firefox 112.0 (from repo)
• Plasma 5.27.4 (Wayland session)
• Frameworks 5.105.0
• Qt 5.15.9
• Kernel 6.2.11

Relevant upstream bug: https://bugs.kde.org/show_bug.cgi?id=465252

Comment 8

[restuccia]

Same problem on my configuration.
Copying from the URL bar, or from right click -> copy link into another application does not work. Copying normal text from a web page and pasting into other apps works.

• Firefox 112.0
• Fedora 37
• KDE Plasma 5.27.4 (on wayland)
• KDE Frameworks 5.104.0
• Qt 5.15.9
• Kernel 6.2.10-200.fc37

Comment 9

[Will]

Interesting that disabling middle-click paste fixes this. Not sure if that points to it being a KDE thing or a Firefox thing, but either way - thanks for noting that down Dragoon Aethis, I've finally got a workaround!

Comment 10

[Dragoon Aethis]

It's the other way around, disabling middle-click paste causes this bug :D

Comment 11

[Darkspirit]

(Dragoon Aethis from comment #7)

• In KDE System Settings, uncheck Workspace Behavior -> General Behavior -> Middle Click: Paste Selected Text
• Log out and restart Firefox in Wayland mode.
• Copying from Firefox into other apps no longer works.

Confirmed on KDE Wayland, Debian Testing.
If "Middle Click: Paste Selected Text" is disabled in KDE Settings>Workspace>General,
copying (Ctrl+C / context menu) text from Firefox' address bar and pasting (Ctrl+V) into gedit/kate/konsole/etc no longer works,
but pasting the URL into Firefox still works
and copying text from websites to gedit/kate/konsole/etc also still works.

Copy (Ctrl+C) a dot from a text editor, try to copy from address bar, try to paste (Ctrl+V) into the text editor, and repeat.
$ MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_ENABLE_WAYLAND=1 mozregression --good 2021-05-01 --bad 2023-04-19 -a https://example.com

6:45.30 INFO: Last good revision: aca153106940b800cac068609f552fc82b2ba2d1 (2021-09-06)
6:45.30 INFO: First bad revision: 2bd46b2573e6e52f396483be1822021b475deb70 (2021-09-07)
6:45.30 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aca153106940b800cac068609f552fc82b2ba2d1&tochange=2bd46b2573e6e52f396483be1822021b475deb70

autoland builds are gone.
Two wayland changes in that change:

870c8ca46ce63b8011938d52b23a5c5904c7c9aa stransky — Bug 1729424 [Wayland] Remove WindowSurfaceWayland backend r=rmader
a4eff1c6ceaf2f25206702d0612f10382a01ed02 stransky — Bug 1729423 [Wayland] Enable async clipboard by default, r=rmader

Disabling widget.wayland.async-clipboard.enabled prevented the problem in the first bad build.
$ MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_ENABLE_WAYLAND=1 mozregression --launch 2021-09-07 --pref widget.wayland.async-clipboard.enabled:false -a https://example.com

But the pref seems to be gone today, it no longer helps:
mozregression --launch 2023-04-20 --pref widget.wayland.async-clipboard.enabled:false -a https://example.com

MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_ENABLE_WAYLAND=1 mozregression --good 2021-09-07 --bad 2023-04-20 --pref widget.wayland.async-clipboard.enabled:false -a https://example.com

5:06.17 INFO: Last good revision: b9121c1a4330a9cd49f44100c6a29d69eec06eec (2022-01-27)
5:06.17 INFO: First bad revision: 32a2d1ce4bab2979c3be01244f100f000ca77d8e (2022-01-28)
5:06.17 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9121c1a4330a9cd49f44100c6a29d69eec06eec&tochange=32a2d1ce4bab2979c3be01244f100f000ca77d8e

autoland builds are gone.
The widget.wayland.async-clipboard.enabled pref has been removed by bug 1752503:

48e8fb0b62c587e64b43e9d51a0dff7fdf4b7b2c stransky — Bug 1752503 [Wayland] Remove DataOffer class r=rmader
b15e8c28c3772533128c9155abeb0ee6f3b5c0c1 stransky — Bug 1752503 [Wayland] Rename nsRetrievalContextWaylandAsync to nsRetrievalContextWayland r=rmader
7471ec11ddaacce1ae73118fcc0e49e1364fbcac stransky — Bug 1752503 [Wayland] Rename nsClipboardWaylandAsync to nsClipboardWayland r=rmader

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Will look at it when I finish my recent workload.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1729423

Comment 16

[Anubhab Ghosh]

Not sure if it is relevant, but the same problem seems to occur when copying links in email body in Thunderbird as well (right click on link -> Copy Link Location). It is also fixed when middle mouse click paste is enabled.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Deferred to further work on GtkClipboard.

Comment 19

[raphael.kiefmann]

Is there any way to track the progress on these issues and its priority? I have to copy from the address bar quite often and the workaround of enabling "Middle Click: Paste Selected Text" causes even more problems for me

Comment 20

[papjk3]

Same here, KDE 5.27.6 on manjaro, firefox 115.0.1

Comment 21

[Andrew Todd]

I think that this KDE bug report is probably related. The workaround of enabling "Middle Click: Paste Selected Text" seems to have worked for me.

https://bugs.kde.org/show_bug.cgi?id=471375

Comment 22

[Strangiato]

I can reproduce with Firefox 115.0.2 running natively on Wayland. Firefox running on Xwayland is not affected.

Comment 23

[David Edmundson]

To translate that KDE setting into how it affects things at a wayland level.

If "Middle Click: Paste Selected Text" is disabled (the broken case) kwin does not create a zwp_primary_selection_device_manager_v1 global.
I don't think anything is wrong at a KDE level.

Comment 24

[Pedro [:pedrov]]

Possibly there's an issue with assuming primary selection exists just based on the platform, although I couldn't find the clipboard capability being set in the GTK specific code while it's clearly set on other paths.

Wayland wasn't really supposed to have primary selection by default, the history of this bug report also shows that it wasn't always around, KDE just seems to be the odd one now because after adding primary selection for everyone with no opting out, finally there's an option to revert back to not having it, so it's optional as it's supposed to be.
Also note that zwp_primary_selection_device_manager_v1 is "X primary selection emulation", further hinting that Wayland is really not supposed to be expected to have this functionality.

Bug 1515783 is mildly related with the oddities of:

• middlemouse.paste defaulting to true on Wayland which is unexpected given the previously mentioned optional emulation
• Primary selection keeps on working even without zwp_primary_selection_device_manager_v1 (so against the user's wishes based on the system's settings)

The issue is surely odd though as it seems to affect only the address bar, and the internal clipboard is fine, the copy is just not propagated to the native clipboard. This allows for the silly workaround of pasting the address elsewhere into the same browser session, then copying it from there, so instead of just Ctrl+C, the following silly dance works: Ctrl+C, Ctrl+F, Ctrl+V, Ctrl+A, Ctrl+C .

Comment 25

[Pedro [:pedrov]]

Just found out that the issue is not address bar exclusive, but so far it's suspiciously URL related.

Right clicking on a link and using "Copy Link" exhibits the same issue.
Copying regular text similarly with the mouse works without a problem. Copying text that happens to be a URL behaves the same correct way.

There's an interesting oddity though, copying a link appears to somewhat break the clipboard as pasting just stops working until something else is copied. This reminds me of KeePassXC breaking the clipboard by attempting to clear it, although that had different symptoms:
https://github.com/keepassxreboot/keepassxc/issues/8492

Generally I recommend considering that there may be multiple problems here as theoretically primary selection isn't really supposed to make a difference at all in this case.

Comment 26

[Pedro [:pedrov]]

Attempted to dig a bit deeper, trying to get familiar with the problematic parts of the code, so tons of assumptions follow due to the lack of familiarity.

UrlbarInput seems to be related, CopyCutController::doCommand appears to handle copying there, calling nsClipboardHelper::CopyString to do the heavy lifting which appears to have a quite bizarre functionality.
Spotting the primary selection usage there made me suspicious, and the "unix also needs us to copy to the selection clipboard" reasoning isn't really convincing to me. Is there a way to copy without selecting first? UrlbarInput even seems to explicitly deal with primary selection on activation, so I believe the answer is no.

It still wasn't obvious how primary selection was breaking copying, figured I'd utilize the useful looking logging (oddly the "all:5" log filter doesn't work), getting this on copying from the address bar:

D/WidgetClipboard nsClipboard::SetData (clipboard)
D/WidgetClipboard     processing target text/plain
D/WidgetClipboard     adding TEXT targets
D/WidgetClipboard nsRetrievalContext::ClearCachedTargetsClipboard()
D/WidgetClipboard nsClipboard::SetData (primary)
D/WidgetClipboard     processing target text/plain
D/WidgetClipboard     adding TEXT targets
D/WidgetClipboard nsRetrievalContext::ClearCachedTargetsPrimary()
D/WidgetClipboard clipboard_clear_cb() callback
D/WidgetClipboard nsClipboard::SelectionClearEvent (primary)
D/WidgetClipboard nsRetrievalContext::ClearCachedTargetsPrimary()
D/WidgetClipboard nsRetrievalContext::ClearCachedTargetsClipboard()

The primary selection not making much sense is not that surprising with the functionality not existing after all, just apparently GTK playing along with a fake clipboard object, however the origin of that last ClearCachedTargetsClipboard() call is not clear to me, suspected the handling of two clipboards getting mixed up, but couldn't find evidence, and I'm unfortunately really not familiar with the apparently callback heavy GTK interface.

So theory is that primary selection usage is messing up the clipboard, and it's always happening for the address bar because it's oddly forced for no apparent good reason. Tested the theory, seemed to work as suspected, but given that it shouldn't be address bar specific, I'm presenting a more generic way to reproduce it which might also explain apparently unreliable clipboard issues:

• Copy some text from Firefox (avoiding the address bar)
• Paste into another program, observe successful clipboard operation
• Select some text in Firefox (just primary selection usage, don't explicitly copy)
• Attempt to paste into another program again, observe failure

In the case of address bar usage I'm not sure if it's a race condition that's just really unlikely to be "won", but the clipboard data never seems to make it out of the process, and the data offer starts out with no payload. In the more generic case of copying regular text, of course it initially works, but it's likely that the primary selection logic later clobbers the data offer as it doesn't look like the clipboard changes, pasting just stops working, so apparently the clipboard isn't explicitly cleared after all.

Figured I'd try to see how a "low budget" fix of just removing the GTK backend advertising primary selection support would go. The initial steps of building Firefox is surprisingly friendly with all dependencies and a whole lot more being dealt with automagically, but then running just complaining about missing libraries was kind of a kick back into the "real" world.
Not sure what was I missing, but unfortunately the built binary was hell bent on connecting to an X11 server in a Wayland-only environment even though Wayland usage was requested in an environment variable. Remembering recent Wayland-only building possibility, opted for that approach, but that oddly failed with compilation error due to something X11-related being attempted to be used which didn't exist, so at that point I gave up (for now).

So this seems to be multiple issues after all:

• UrlbarInput is messing with the primary selection on copy even though I believe that doesn't make sense. Not sure if nsClipboardHelper::CopyString can be changed as it seems to have quite a few other users, but if it would be modified to make primary selection usage optional with UrlbarInput's copy handler opting out (due to explicit primary selection handling elsewhere), then that would already deal with this bug report as one possible cheap solution.
• The GTK clipboard backend is advertising primary selection support blindly "X11 style". On Wayland it should check if primary selection emulation is supported, marking primary selection unsupported if it isn't. This would fix not just the UrlbarInput issue, but other cases of primary selection messing with the global clipboard too, although I still recommend altering the UrlbarInput copying logic, there's a reason why that's fully broken on its own while copying from elsewhere is at least okayish. Of course this approach needs more development effort.

Comment 27

[peelz]

The problem goes away if I get rid of this:

diff -r 6089e7f0fa57 widget/nsClipboardHelper.cpp
--- a/widget/nsClipboardHelper.cpp
+++ b/widget/nsClipboardHelper.cpp
@@ -101,23 +101,12 @@
 NS_IMETHODIMP
 nsClipboardHelper::CopyString(const nsAString& aString,
                               SensitiveData aSensitive) {
   nsresult rv;
 
   // copy to the global clipboard. it's bad if this fails in any way.
   rv = CopyStringToClipboard(aString, nsIClipboard::kGlobalClipboard,
                              aSensitive);
   NS_ENSURE_SUCCESS(rv, rv);
 
-  // unix also needs us to copy to the selection clipboard. this will
-  // fail in CopyStringToClipboard if we're not on a platform that
-  // supports the selection clipboard. (this could have been #ifdef
-  // XP_UNIX, but using the IsClipboardTypeSupported call is the more correct
-  // thing to do.
-  //
-  // if this fails in any way other than "not being unix", we'll get
-  // the assertion we need in CopyStringToClipboard, and we needn't
-  // assert again here.
-  CopyStringToClipboard(aString, nsIClipboard::kSelectionClipboard, aSensitive);
-
   return NS_OK;
 }

Following the function calls: CopyStringToClipboard calls ClipboardSetDataHelper::SetData (widget/nsBaseClipboard.cpp), which calls the GTK-specific implementation of nsClipboard::SetNativeClipboardData (widget/gtk/nsClipboard.cpp).

I'm not very familiar with GTK's clipboard API, but after poking around, I noticed that gtk_clipboard_set_with_data appears to trigger the bug.

Using this patch, the problem goes away:

diff -r 6089e7f0fa57 widget/gtk/nsClipboard.cpp
--- a/widget/gtk/nsClipboard.cpp
+++ b/widget/gtk/nsClipboard.cpp
@@ -331,10 +331,12 @@ nsClipboard::SetNativeClipboardData(nsIT
     return NS_ERROR_FAILURE;
   }
 
   ClearCachedTargets(aWhichClipboard);
 
+  if (aWhichClipboard == kSelectionClipboard) goto ret;
+
   // Set getcallback and request to store data after an application exit
   if (gtk_clipboard_set_with_data(gtkClipboard, gtkTargets, numTargets,
                                   clipboard_get_cb, clipboard_clear_cb, this)) {
     // We managed to set-up the clipboard so update internal state
     // We have to set it now because gtk_clipboard_set_with_data() calls
@@ -353,10 +355,11 @@ nsClipboard::SetNativeClipboardData(nsIT
     LOGCLIP("    gtk_clipboard_set_with_data() failed!\n");
     EmptyClipboard(aWhichClipboard);
     rv = NS_ERROR_FAILURE;
   }
 
+ret:
   gtk_target_table_free(gtkTargets, numTargets);
   gtk_target_list_unref(list);
 
   return rv;
 }

I did my testing by running Firefox like this:

./mach build
# XXX: for some reason MOZ_ENABLE_WAYLAND=1 wasn't enough to make Firefox use Wayland on my machine
# ...even though it works on the regular release version of Firefox (v119)
DISPLAY= GDK_BACKEND=wayland MOZ_ENABLE_WAYLAND=1 MOZ_LOG='WidgetClipboard:5,Clipboard:5' ./mach run

In the meantime, I made a hacky LD_PRELOAD-able library to work around this issue (it turns all of GTK's primary clipboard functions into no-ops): https://github.com/notpeelz/gtkclipblock

Comment 28

[Pedro [:pedrov]]

My Wayland-only building attempt in a container didn't work out, so can't test in this environment as planned to, but I believe that I have an okay understanding of the problem anyway to have a good guess.

Assuming that the regression of removing the primary selection functionality which may be still desired by some, I'd like to propose reordering the usage of kGlobalClipboard and kSelectionClipboard as a temporary solution, so the later doesn't end up clobbering the former. Piggybacking on peelz's comment, I believe that in the first diff instead of removing the kSelectionClipboard usage, we could have the following instead:

 NS_IMETHODIMP
 nsClipboardHelper::CopyString(const nsAString& aString,
                               SensitiveData aSensitive) {
   nsresult rv;

   // unix also needs us to copy to the selection clipboard. this will
   // fail in CopyStringToClipboard if we're not on a platform that
   // supports the selection clipboard. (this could have been #ifdef
   // XP_UNIX, but using the IsClipboardTypeSupported call is the more correct
   // thing to do.
   //
   // if this fails in any way other than "not being unix", we'll get
   // the assertion we need in CopyStringToClipboard, and we needn't
   // assert again here.
   CopyStringToClipboard(aString, nsIClipboard::kSelectionClipboard, aSensitive);
 
   // copy to the global clipboard. it's bad if this fails in any way.
   rv = CopyStringToClipboard(aString, nsIClipboard::kGlobalClipboard,
                              aSensitive);
   NS_ENSURE_SUCCESS(rv, rv);
 
   return NS_OK;
 }

While this technically doesn't get rid of the incorrect unconditional primary selection usage, it should at least prevent the copying issue from the address bar.

That may also fix the issue with the "Copy Link" context menu as it seems like that leads to the mentioned function too (although I'm not fully confident):

• main-context-menu-copy-link-simple =\n .label = Copy Link ->
• data-l10n-id="main-context-menu-copy-link-simple"\n oncommand="gContextMenu.copyLink();"/> ->
• clipboard.copyString(linkURL); -> [...]

Comment 29

[stefanfunk1998]

the firefox update 121, which uses the wayland implementation by default, just hit the arch linux repositories, and this bug is still there, which is quite detrimental to actually trying to use the browser.

Comment 30

[Martin Stránský [:stransky] (ni? me)]

Yes, we should look at it ASAP.

Comment 31

[Marius Bosler [:maribox]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #30)

Yes, we should look at it ASAP.

So glad to read this.
I can use Firefox on every machine except on KDE/Wayland (my main machine) because this bug annoys me so much :D

Comment 32

[andy]

For Thunderbird's Copy Link Location: my workaround is to open a new message to compose, paste the link location in the body, then select it and use Ctrl+C to copy it again. So at least the clipboard works within the application. I share in case this hints at anything useful for implementing a solution.

The same workaround seems to work for firefox too, to paste the text somewhere else within the application (e.g. an html form) and then Ctrl+C it again.

Comment 33

[nortexoid]

drag and drop works, i.e. drag and drop the selected url e.g. into a text editor and it copies it there. A shame this bug has been around for ever and now that firefox defaults to wayland, it's even more worrying.

Comment 34

[bevgeniys]

Sometimes I think the only way for the bug to be addressed is for person who actually responsible to finally experience it and live with it for a while. Only then they would understand how annoying it is and will finally address it

Comment 35

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1791417 [Wayland] Get primary/selection status from Wayland display r?emilio

Comment 36

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1791417 [Wayland] Don't advertise selection clipboard support if it's disabled r?emilio

Depends on D198140

Comment 37

[Martin Stránský [:stransky] (ni? me)]

Sorry for the delay here. The diagnosis here are correct, we should not claim selection clipboard support if it's not supported.

You can also submit the patches yourself, any contribution is very welcome. There's a mini-howto here:
https://mastransky.wordpress.com/2023/07/04/no-one-fights-alone-a-guide-to-your-first-firefox-patch-on-linux/

I'll try to look at more KDE bugs but any help will speed up the process.
Thanks.

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/626a7eaa4a69
[Wayland] Get primary/selection status from Wayland display r=emilio
https://hg.mozilla.org/integration/autoland/rev/4e9b166a0042
[Wayland] Don't advertise selection clipboard support if it's disabled r=emilio

Comment 39

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/626a7eaa4a69
https://hg.mozilla.org/mozilla-central/rev/4e9b166a0042

Comment 40

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:stransky, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox122 to wontfix.

For more information, please visit BugBot documentation.

Comment 41

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 9371974 [details]
Bug 1791417 [Wayland] Get primary/selection status from Wayland display r?emilio

Beta/Release Uplift Approval Request

• User impact if declined: Broken copy&paste on KDE with disabled selection clipboard.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We follow system settings and disable selection clipboard if it's not available. No tricky part here.
• String changes made/needed:
• Is Android affected?: No

Comment 42

[Donal Meehan [:dmeehan]]

Comment on attachment 9371974 [details]
Bug 1791417 [Wayland] Get primary/selection status from Wayland display r?emilio

Approved for 122.0 RC1

Comment 43

[Donal Meehan [:dmeehan]]

Comment on attachment 9371975 [details]
Bug 1791417 [Wayland] Don't advertise selection clipboard support if it's disabled r?emilio

Approved for 122.0 RC1

Comment 44

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/908c828f8285
https://hg.mozilla.org/releases/mozilla-beta/rev/fce09187420b

Comment 45

[Peter Magyari (Desktop QA)]

I attempted to verify the fix but I wasn't able to reproduce the issue on my Ubuntu 20.04 + KDE plasma on either x11 or wayland.
Could any of you guys please verify the fix on the Latest Nightly and Latest Beta(122.0 RC1) builds?

Thank you!

Comment 46

[Marius Bosler [:maribox]]

(In reply to Peter Magyari (Desktop QA) from comment #45)

I attempted to verify the fix but I wasn't able to reproduce the issue on my Ubuntu 20.04 + KDE plasma on either x11 or wayland.
Could any of you guys please verify the fix on the Latest Nightly and Latest Beta(122.0 RC1) builds?

Thank you!

I was able to verify the fix on my machine, but just on the latest nightly, 123.0a1 (2024-01-16), not on the latest Beta, 122.0b9.

I downloaded both versions from the Firefox download page and also built Firefox myself for the first time (with the rev above), but neither the finished beta build, nor the build I made my own (I pulled mozilla-unified with bootstrap.py, hg update -r fce09187420b76e0cca6787b624f7c507b1915d0, ./mach build) worked.

I'm sorry if I made a mistake here :/

Comment 47

[Peter Magyari (Desktop QA)]

Hi Marius,

Thank you for your quick response, the fix won't be on 122.0b9 but the update should already be available on your Firefox Beta to 122.0 RC.
Here is a direct download link to the 122.0 RC (en-US) build: https://ftp.mozilla.org/pub/firefox/candidates/122.0-candidates/build1/linux-x86_64/en-US/firefox-122.0.tar.bz2

In the meantime, I'm marking Nightly 123.0a1 as verified.

Thanks again!

Comment 48

[Marius Bosler [:maribox]]

No worries, I'm happy too when this bug finally gets resolved! :D

I was able to verify the fix on 122.0 RC also.

Can you maybe quickly explain why there's no "RC"-Tag or similar in https://hg.mozilla.org/releases/mozilla-beta/tags (which is where I looked for the RC version) and maybe guess why my self-made build did not yet include the fix? (even though I tried to check out at above rev)
Where should I have looked for the Code/Tag/Build-Download of 122.0 RC?

Comment 49

[Peter Magyari (Desktop QA)]

For the RC build the correct repository would be-> https://hg.mozilla.org/releases/mozilla-release/ (in this case Firefox_122_0_build1)
Since 122.0b9 is the last Beta build, and the next Beta will be 123.0b1, you cannot find the RC builds in the Beta repository.
You can also find these builds here: https://ftp.mozilla.org/pub/firefox/candidates/
The ones without b1-b9 are the RC builds. (for example 121.0 and 121.0.1)

Thank you for verifying!