Description of problem: Applications under gnome-shell in wayland cut-and-paste is slow if they are running on different workspaces. The copy-from application needs to be visible. In other words, you need to cycle through the workspaces before the paste happens. Version-Release number of selected component (if applicable): Fedora 25 Beta How reproducible: Always Steps to Reproduce: 1. Start an app on workspace 1 (epiphany or evolution) 2. create workspace 2 3. run gedit on workspace 2 4. select text in epiphany (url bar or web page content) 5. right-click copy 6. go to workspace 2 7. paste in gedit Actual results: Nothing happens 8. move to workspace 1 9. move to workspace 2 now the text is copied Expected results: Text is copied immediately Additional info: I've tried to/from evolution, epiphany, firefox, gedit, gnome-calculator Copy from evolution and epiphany exhibit this. These are both webkitgtk apps. Copying in epiphany from the URL bar *also* exhibits this. I assume the URL bar is a normal gtk widget. workaround is to move back-and-forth between workspaces to get the copy to trigger.
(In reply to Berend De Schouwer from comment #0) > Copy from evolution and epiphany exhibit this. These are both webkitgtk > apps. Copying in epiphany from the URL bar *also* exhibits this. I assume > the URL bar is a normal gtk widget. Yup. If you're sure the URL bar is affected but apps that don't use WebKitGTK+ are not, then that doesn't make any sense. Also, I have no clue why the workspace the windows are on affects this. That should not matter at all. If not for those two issues, I would say this is probably a WebKit bug, but due to those I can safely say I have no clue what's going on.
-> gtk3 I guess. If not for the claim that this affects the URL bar, I'd say this is WebKit's fault, but I don't see how we could possibly break the URL bar. In any case, this gets it closer to the right developers, even if it turns out to be the wrong product.
Tested again All tests paste into gedit on a different workspace All tests paste text All tests use context menus gtk: gnome-terminal: works gnome-calculator: works evolution (mail): broken evolution (view source): broken evolution (subject): broken epiphany (url bar): broken epiphany (website): broken gnome-builder: works gnome-music (search bar): works nautilus: works gnome-shell: works gnome-font-viewer (description): works qt: konsole: works other: firefox is currently linked against gtk3 firefox (website): works firefox (url bar): works geeqie (gtk2/x11): works chrome (url bar): works chrome (website): works I then repeated with pasting into gnome-calculator, to the same result.
I can paste into the epiphany URL bar from gedit immediately. I cannot paste into the epiphany URL bar from evolution on a different workspace, no matter what I try. I can paste into the epiphany URL bar from evolution provided they are on the same workspace. Then it pastes immediately. (possibly related, launching two epiphany windows on different workspaces makes epiphany crawl.)
mcatanzaro: https://bugzilla.redhat.com/show_bug.cgi?id=1396009 mcatanzaro: User insists that whether copy-paste works is workspace-dependent: "I cannot paste into the epiphany URL bar from evolution on a different workspace, no matter what I try." mcatanzaro: And KaL: "(possibly related, launching two epiphany windows on different workspaces makes epiphany crawl.)" ...really...? garnacho_: mcatanzaro: I tbh saw that once, when I first switched back from compiled webkit to f25 ones after the clipboard change made it to tarballs, never since then. I assumed it got fixed in the mean time garnacho_: mcatanzaro: what IIRC happened is that it waited for a frame callback that wouldn't happen until you switch to the browser workspace again, so the wayland source didn't get throttled, and no further events were handled mcatanzaro: garnacho_: Wow, it really IS workspace-dependent mcatanzaro: Aaaaand could that explain why running ephy's UI process on two different workspaces is reported to suck? mcatanzaro: (Rember two ephy windows = just one process usually) mcatanzaro: I should believe bug reporters more often. garnacho_: mcatanzaro: no idea about that one... supposedly a frame callback not running would just affect the surface it notifies about OK, it looks like we have three different bugs here: one for slow copy/paste, one for nonfunctional copy/paste, and one for the slow performance in general. They all need to be reported on bugzilla.webkit.org, against the WebKitGTK+ component, with the prefix [GTK] at the start of the title of the bug. I can report these upstream if you want, but it'd be better if you do so as then you'll be able to comment and get emails. Do you want to do it, Berend?
I think "slow" and "nonfunctional" c&p might be the same perceived issue. When I saw this, I found that switching to the workspace containing the clipboard-source browser resulted in the clipboard content immediately pasted on the other side. Now, if that never happens, or you copy something else in between, the whole thing becomes cancelled.
I'm creating the three bug reports now. I thing that "no copy" can be introduced by a slow webkit on one workspace and impatience on the user side. I think that it should be tested after the other two bugs are fixed. "slow" can also result in the context menu popping up on another workspace 10 seconds after you've attempted to access the context menu, and now it's not associated with a window.
*** Bug 1373917 has been marked as a duplicate of this bug. ***
Given that this is a functionality breakage in F25, doesn't it make sense to keep the bug open until it is resolved, rather than closing as upstream? I have had this issue but by seeing several bugs closed as upstream, I had no idea whether it was actually resolved, or simply forwarded upstream.
(In reply to Nikos Mavrogiannopoulos from comment #9) > Given that this is a functionality breakage in F25, doesn't it make sense to > keep the bug open until it is resolved, rather than closing as upstream? I > have had this issue but by seeing several bugs closed as upstream, I had no > idea whether it was actually resolved, or simply forwarded upstream. I usually prefer to track WebKit bugs in upstream Bugzilla. For particularly serious issues I agree it makes sense to keep the issue open downstream so we can use it to track a Fedora update. Anyway, this turned out to be a GTK+ bug that doesn't have a solution yet: https://bugzilla.gnome.org/show_bug.cgi?id=769835
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.