Gnome3 firefox-60.0.1-5.fc28.x86_64

This happens when I press Super key.
This happens when I press Alt+Shift.
This happens when I press Super+Space to change layout.
This happens when I move mouse pointer to up left corner

(In reply to Serge van Thillo from comment #0)
> 2. Try to paste it in gedit for example
> 3.

> Actual results:
> Paste buffer stays empty

Empty only when you switch between windows by Alt+Shift. But when you switch between windows by mouse clicking and then press Ctrl+V paste happens.

In previous my comment
> Empty only when you switch between windows by Alt+Shift.
of course by Alt+Tab not by Alt+Shift.

Also doesn't work switch between tabs by alt+N (Alt+1, Alt+2 etc).

I think how you switch windows has not a lot to do with it. At least I can reproduce it in a multi-screen setup. In general it only works sometimes and sometimes it does not. Also seems to depend on whether you press Ctrl+C or use right-click -> copy.

The only thing that always works is when you copy text in Firefox only, i.e. not in a different window.

Also copying text *into* Firefox from a different window always seems to work.

(In reply to rugk from comment #3)
> Also seems to depend on whether you press Ctrl+C or
> use right-click -> copy.

No difference.Try: 
Ctrl+C (or right-click -> copy) - Alt+Tab - Ctrl+V (or right-click -> paste)
Ctrl+C (or right-click -> copy) - Super+Space - Ctrl+V (or right-click -> paste)

As a workaround to copying text from Firefox to some other application, you can select the text, and then drag and drop it into the application.

*** Bug 1589502 has been marked as a duplicate of this bug. ***

*** Bug 1592142 has been marked as a duplicate of this bug. ***

I'm wondering if there's an upstream bug for this one?
The only copy-paste related bug I may find in Firefox bugzilla is https://bugzilla.mozilla.org/show_bug.cgi?id=1434572 "[Wayland] copy -> paste between Firefox windows does not work" which was resolved 4 months ago and anyways seems to have nothing to do with other applications.

Actually with the update to Firefox 61 my FF works again.

BTW as for STR: You could only copy it when you use a multi-monitor setup, have gedit started and on the second screen. If you then copy a text and first past it in gedit, you can then paste it anywhere.
If your gedit is on the same screen as Firefox (or maybe the secondary screen in general) it works.

So I would close this bug (cannot do so due to permissions), but unless someone else can reproduce it in Firefox 61 I guess it is fine to close this one.

Well I have a single monitor setup (only laptop with no external screen) and copy from FF-on-Wayland doesn't work to other applications. Though inside FF copy-paste seems to work, i.e. I may copy text from web-page content and past it in say address bar.

Note neither Ctrl-C not copy via context-menu work.
FWIW this is my FF info:
----------------------------------->8------------------------------
# dnf info firefox-wayland-61.0-4.fc28.x86_64 
Last metadata expiration check: 0:43:36 ago on Sun 01 Jul 2018 07:42:51 AM PDT.
Installed Packages
Name         : firefox-wayland
Version      : 61.0
Release      : 4.fc28
Arch         : x86_64
Size         : 8.0 k
Source       : firefox-61.0-4.fc28.src.rpm
Repo         : @System
From repo    : updates
Summary      : Firefox Wayland launcher.
URL          : https://www.mozilla.org/firefox/
License      : MPLv1.1 or GPLv2+ or LGPLv2+
Description  : The firefox-wayland package contains launcher and desktop file
             : to run Firefox natively on Wayland.
----------------------------------->8------------------------------

Copy-paste between FF61 on Wayland and Emacs is definitely still not working. I can copy in FF61 and then paste into a Gnome app like the text editor or terminal but not being able to go between FF and Emacs is a serious problem for me.

Actually, even just switching focus to the Gnome text editor and then to Emacs will make copy-paste or middle-click. If I switch focus directly to Emacs from FF then copy-paste and middle-click fail.

It’s only partially working for me. I can copy and paste from within the same window. I can’t copy from one window over to another window or to a window belonging to another application.

Guys, if you have such problems with copy paste can you please install some clipboard manager (gpaste for instance or clipit) and check what's the actual clipboard content and if firefox<->clipboard or clipboard<->"other app" operation  fails and also what's mime type content of the clipboard. Thanks!

Also I expect everyone uses gnome-shell/mutter as Wayland compositor, correct?

(In reply to Martin Stransky from comment #15)
> Also I expect everyone uses gnome-shell/mutter as Wayland compositor,
> correct?

Yes

I am also in the same situation as the others, however, to try to solve the situation I am using the "Clipboard Indicator" extension.

It doesn't solve the issue at all but at least it works for me (I just have to add a couple more clicks to my workfow).

Best regards.

I can reproduce that somehow:

1) copy something to clipboard
2) switch Firefox window, try to paste
3) paste fails
4) switch to another firefox window/switch back and/or to another application (gpaste for instance)
5) paste works

Looks like the copy is not fast enough, is blocked somehow and focus in/out is needed to propagate data to clipboard.

For me the most reliable copy-paste way to use with firefox-wayland is the side-by-side placement of the firefox window (source for clipboard) and a destination window, e.g. gedit.
Drag-and-drop of a selected text works as well but is not much convenient for me.

Any other way via switch between the firefox and a destination window (with keyboard hot keys or via upper-left screen corner) sporadically fails and stops to work.

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

(Adding myself to the CC: list. I can reproduce this consistently with firefox-wayland-62.0-2.fc28 on stock Gnome 3 under Wayland.)

Let's wait how it behaves on Fedora 29 and gtk 3.24 - it contains mutter clipboard fixes.

I have the same issue here, though I'm using Arch Linux. I cannot copy and paste anything out from Firefox, not even when switching applications, changing focus, etc.

Package versions: 
gnome-shell 3.30.0+25+g179cd0a3c-1
gtk3 3.24.0+33+g8fd2d461fc-1
mutter 3.30.0-2
firefox-wayland 62.0-1, built from source according to this PKGBUILD: https://aur.archlinux.org/packages/firefox-wayland/

Still a problem with:

gtk3-3.24.1-1.fc29.x86_64
mutter-3.30.0-3.fc29.x86_64
firefox-wayland-62.0.3-1.fc29.x86_64
gnome-shell-3.30.0-9.fc29.x86_64

(In reply to Juan Orti from comment #24)
> Still a problem with:
> 
> gtk3-3.24.1-1.fc29.x86_64
> mutter-3.30.0-3.fc29.x86_64
> firefox-wayland-62.0.3-1.fc29.x86_64
> gnome-shell-3.30.0-9.fc29.x86_64

Can you elaborate more what is the problem? Can you also check clipboard content (by $gpaste-client --reverse or some other clipboard manager) to find out if the content is missind in the clipboard or Firefox fails to get data from the clipboard.

Also please try firefox-wayland-62.0.3-2.fc29.x86_64 package from https://koji.fedoraproject.org/koji/buildinfo?buildID=1151429

I'm running an upgraded Fedora 29 with firefox-62.0.3-4.fc29.x86_64 that contains all the wayland patches. I still see this. Trying to copy both the window content, and from the url bar. I have also tried using both Ctrl+C and select text and right click selection and choosing "Copy" in the popup menu. When I in gedit right-click to get the popup the "Paste" menu item is disabled. 
Even if I previously have something in the clipboard, try to copy something in firefox, then try to paste it, it still is disabled.... so it seems like the clipboard is cleared, but not filled with the new content.

I can't copy from firefox-wayland, neither Ctrl-C nor selection and mouse middle click.

However, if I copy from any other application, I can paste ans selection-paste in Firefox.

gpaste-client --reverse crash with a segmentation fault :( (bug 1638136)

The versions tested are:
gtk3-3.24.1-1.fc29.x86_64
mutter-3.30.1-1.fc29.x86_64
firefox-wayland-62.0.3-4.fc29.x86_64
gnome-shell-3.30.1-1.fc29.x86_64

I see, thanks. Firefox uses standard Gtk+ API to paste to clipboard so I wonder why it happens.

Can you reproduce that regularly? If so, can you please run:

WAYLAND_DEBUG=1 firefox > log.txt 2>&1

and attach the log when the paste fails here.

Thanks.

Created attachment 1494150 [details]
Wayland log where copy paste did not work

I attached a Wayland log as requested, where copy paste did not work. As soon as copy paste did not work I closed Firefox to prevent the log filling with other events.

It's interesting that pasting works after I ran `gpaste-client`.

Interestingly enough, I had now also a problem with copy-pasting between two gedit windows. Note that the copy paste is not continuously broken. It takes some time until the problem appears. Only restarting the application fixes it then. Sometimes several restarts are required to get copy paste working again in Firefox.

Upstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1485916

It may be related to a general Gkt+ Wayland clipboard bug:
https://gitlab.gnome.org/GNOME/gtk/issues/66

*** Bug 1640023 has been marked as a duplicate of this bug. ***

I've tried to reproduce it again.

1. I've copied longer text (contents of https://gitlab.gnome.org/GNOME/gtk/issues/66) and tried to paste it. It didn't work. 

2. I did the same thing but with gpaste (gpaste daemon running)  and it worked without issues.

3. I killed gpaste daemon, tried to copy & paste again and it didn't worked again.

It looks like gpaste can be used as workaround.

This is a work around: when copy paste stops working in Firefox, type in a terminal:

gpaste-client

And copy paste starts working again.

Okay, moving to mutter as it should be related. Firefox uses standard Gtk+ API to copy data to clipboard, I don't think we can do anything on Firefox side here.

May be related to https://gitlab.gnome.org/GNOME/gtk/issues/66

About using standard API, there must be something different about how Firefox uses it since this problem only affects Firefox. Normal gnome apps work perfectly, but Firefox only works when gpaste is running. Is there some mainloop hook that is missig? Causing the Gtk clipboard api not to be monitored correctly or something? Just throwing ideas around with out any real knowledge about Gtk clipboard implementation...

BTW: same on Firefox 63 (from koji)

It's not restricted to Firefox. I'm also see missing clipboard data from non-Wayland application like Thunderbird or wayland-based like gnome-terminal.

When the text fails to copy to clipboard, I need to mark the text and repeat the copy.

I confirm the bug.
I cannot copy & past between firefox-wayland and other applications.
I cannot copy & past between firefox-wayland windows.

Previously, I suggested Drang & Drop as a workaround, but after recent updates, even that does not work. This is a desperate situation.

Just FTR, the drag&drop seems to be really broken. Whenever I select anything and start to drag the cursor does not change.

$ rpm -q firefox
firefox-63.0-2.fc30.x86_64

$ rpm -q mutter
mutter-3.30.1-5.fc30.x86_64

As for the copy/paste - can you check if the problem is with copy or paste? You can check your actual clipboard content by gpaste-client --reverse.

(In reply to Martin Stransky from comment #45)
> As for the copy/paste - can you check if the problem is with copy or paste?
> You can check your actual clipboard content by gpaste-client --reverse.

First call to "gpaste-client --reverse" segfaulted: bug 1645435. Maybe it is not just a coincidence.

I'll try to observe the situation because, since the segfault, copy/paste seems to work.

You may try "clipit -c".

(In reply to Martin Stransky from comment #47)
> You may try "clipit -c".

But the "gpaste-client" works just fine after the initial crash as well as the copy/paste in FF. So I wonder if the clipboard did not have some weird content from the beginning, which was somehow cleaned up/resolved by the gpaste-client crash.

BTW forgot to mention that the drag&drop works again with:

~~~
$ rpm -q firefox
firefox-63.0.1-1.fc30.x86_64
~~~

But the middle button paste does not work. It works just internally in FF, not to other applications.

The middle paste (primary) should also work - you can see the content by "clipit -p".

I did a small test when copy paste stopped working within Firefox:
* I noticed that copy paste did not work any more
* I selected some text and did ctrl-c, I also left some other text selected
* clipit -c gave no results
* clipit -p gave no results
* I executed on the command line: gpaste-client
* I selected again some text and did ctrl-c and again left some other text selected
* clipit -c gave the text that I copied with ctrl-c
* clipit -p gave also the text that I copied with ctrl-c (also if I select text in for example gedit)

So it seems that executing gpaste-client fixes copy pasting with ctrl-c, ctrl-v, but not with the middle mouse button. And the issue (at least with the middle mouse button) is not specific for Firefox.

Thanks. New build with a clipboard fix is here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1160409

(In reply to Martin Stransky from comment #52)
> Thanks. New build with a clipboard fix is here:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1160409

This build fixes the issue. Thanks!

Let's take it back to Firefox as it's a Firefox bug after all.

firefox-63.0.1-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0593841ea0

firefox-63.0.1-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2d09c093cc

firefox-63.0.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8799cdf191

https://bodhi.fedoraproject.org/updates/FEDORA-2018-2d09c093cc

Fix issues only partially. Copy & paste work from outside app into firefox. Not from firefox outside.

Created attachment 1502419 [details]
video showing proper copy&paste

humm, works fine here with the package from here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1160409

firefox-63.0.1-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8799cdf191

firefox-63.0.1-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2d09c093cc

firefox-63.0.1-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0593841ea0

firefox-63.0.1-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e485c3c4cb

firefox-63.0.1-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9ead2a6776

Hi,

firefox-63.0.1-5.fc29 looks good. 'Bi-directional copy&paste' works for me now. 

Thank you!

What is wrong with the F30 build?

I can confirm that firefox-wayland-63.0.1-5.fc29 works for me (firefox-wayland-63.0.1-1.fc29.x86_64 did not).

firefox-63.0.1-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9ead2a6776

firefox-63.0.1-5.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e485c3c4cb

firefox-63.0.1-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

firefox-63.0.1-5.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

firefox-63.0.3-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-382362e255

firefox-63.0.3-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-382362e255

firefox-63.0.3-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2e905b793c

firefox-63.0.3-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2e905b793c

firefox-63.0.3-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Seems that firefox-63.0.3-3.fc30.x86_64 with sway 1.0 beta is stuck with the
situation as described in [comment 58].  Will report if anything changes.

re [comment 77]:

Better description of the observed situation is rather:

copy \ copy to|    Firefox   |   Firefox   | libreoffice  | urxvt256c-ml|
from  \       |(GTK3/Wayland)|  (GTK3/X11) |(GTK3/Wayland)|    (X11)    |
--------------+--------------+-------------+--------------+-------------+
   Firefox    |              |             |              |neither of:  |
(GTK3/Wayland)|     OK       |     OK      |      OK      |PRIM,CLIP,DD |
--------------+--------------+-------------+--------------+-------------+
   Firefox    |              |             |              |             |
  (GTK3/X11)  |    not DD    |     OK      |    not DD    |   not DD    |
--------------+--------------+-------------+--------------+-------------+
  libreoffice |              |             |              |             |
(GTK3/Wayland)|    not DD    |    not DD   |      OK      |   not DD    |
--------------+--------------+-------------+--------------+-------------+
 urxvt256c-ml | PRIM only    | PRIM only   | PRIM only    | PRIM only   |
     (X11)    |(unsure CLIP) |(unsure CLIP)|(unsure CLIP) |(unsure CLIP)|
--------------+--------------+-------------+--------------+-------------+

Abbreviations used:
PRIM ... primary selection
CLIP ... clipboard (did not verify if it's not doing PRIM under the hood
                    in some circumstances, since I was selecting the
                    text, then doing Ctrl+C, move over, Ctrl+V)
DD   ... drag & drop of the selected text
OK ~ PRIM + CLIP + DD

Hence, the emergency workaround for the Firefox/Wayland -> urxvt256c-ml
for me is to copy a text into libreoffice first (as captured above, this
works and by all the means!), then from here to terminal/wherever else.

I see there's way too many moving parts involved, so that's not
necessarily a problem in Firefox/Wayland, however, what does libreoffice
do differently that primary selection works in the direction of
urxvt256c-ml when allegedly the same "desktop stacks" are leveraged?

Interesting, Thanks.

I think you may compare MIME types which Firefox advertises for a text selection and compare it with the ones provided by libreoffice. 

I expect urxvt256c-ml does not find suitable MIME at clipboard so it refuses to paste (especially when urxvt256c-ml -> Firefox works).

Any hint for really simple way of dumping complete contents of
the clipboard?

And I could live with broken clipboard if primary worked, but
there seems to be a catch as well for some reason, but thanks
to https://github.com/akkana/scripts/blob/master/pyclip,
it can be worked around quite easily, I've discovered
(initial GTK2 method works, so this is not a Firefox/Wayland
integration problem per se).

There's some WIP for sway/wlroots so I'll see if that helps:
https://github.com/swaywm/wlroots/issues/1367

OS: The KDE spin of 64-bit Fedora 29. Everything is up-to-date.

firefox-wayland doesn't launch, unless firefox was opened, firstly.
Terminal output in case of firefox-wayland without firefox: $ firefox-wayland

(firefox:9542): Gtk-WARNING **: 14:12:09.783: cannot open display: :0

re [comment 81]:

Does it relate to your [comment 42]?  If so, which version started well
as "firefox-wayland" and which started to be problematic?

* * *

Regarding sway, this patch for wlroots fixes the problem for me:
https://github.com/swaywm/wlroots/pull/1405
Thanks for the hint regarding the MIME types.

(In reply to Jan Pokorný [poki] from comment #82)
> re [comment 81]:
> 
> Does it relate to your [comment 42]?  If so, which version started well
> as "firefox-wayland" and which started to be problematic?
> 
> * * *
> 
> Regarding sway, this patch for wlroots fixes the problem for me:
> https://github.com/swaywm/wlroots/pull/1405
> Thanks for the hint regarding the MIME types.

The first comment was when I had had Fedora 28. I could launch the program.
The second comment is for Fedora 29 KDE spin.

I upgrade to Firefox 64 in stable and the bug still exists. This bug must be open.

I have this problem too!

(In reply to ali.sherif10 from comment #81)
> OS: The KDE spin of 64-bit Fedora 29. Everything is up-to-date.
> 
> firefox-wayland doesn't launch, unless firefox was opened, firstly.
> Terminal output in case of firefox-wayland without firefox: $ firefox-wayland
> 
> (firefox:9542): Gtk-WARNING **: 14:12:09.783: cannot open display: :0

Sounds like a completely separate issue.
If firefox-wayland "launches" when "firefox" is running, that only means that
you get a new window from the originally-running firefox.
If sounds like your session from which you're starting firefox-wayland
is not configured properly. Also, apparently you were not testing copy&paste
in firefox-wayland, but just plain ol' firefox.

(In reply to Dmitry Teplyakov from comment #85)
> I have this problem too!

Without any details there's nothing that can be fixed.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #86)
> (In reply to ali.sherif10 from comment #81)
> > OS: The KDE spin of 64-bit Fedora 29. Everything is up-to-date.
> > 
> > firefox-wayland doesn't launch, unless firefox was opened, firstly.
> > Terminal output in case of firefox-wayland without firefox: $ firefox-wayland
> > 
> > (firefox:9542): Gtk-WARNING **: 14:12:09.783: cannot open display: :0
> 
> Sounds like a completely separate issue.
> If firefox-wayland "launches" when "firefox" is running, that only means that
> you get a new window from the originally-running firefox.
> If sounds like your session from which you're starting firefox-wayland
> is not configured properly. Also, apparently you were not testing copy&paste
> in firefox-wayland, but just plain ol' firefox.

At first, I had the previous version of Fedora Gnome where I could launch firefox-wayland and get the copy-&-paste bug.
Now, I have the KDE spin of the latest version of Fedora where I can't launch launch firefox-wayland.

Then it's a different bug. Please don't report unrelated problems here, it just makes issues harder to follow.