Bug 2318389 - Middle mouse button inserts primary clipboard twice
Summary: Middle mouse button inserts primary clipboard twice
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: webkitgtk
Version: 40
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Michael Catanzaro
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-10-13 07:04 UTC by pkoz
Modified: 2024-10-23 02:51 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-10-23 01:33:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description pkoz 2024-10-13 07:04:36 UTC
When editing a new Plain text or HTML email, the middle mouse button inserts the contents of the primary clipboard two times: once on press, once on release. Very irritating.

When the format is any one of the Markdowns, insertion works as expected, as well as when editing the Description field of a new calendar event or task.

Explicit clipboard copy/paste operations seem to work all right.

I did not encounter so far any other application in fc40 with this middle button behavior.

$ evolution --version
evolution 3.52.4 (3.52.4-1.fc40) 


Reproducible: Always

Comment 1 Milan Crha 2024-10-14 07:46:26 UTC
Thanks for a bug report. The plain text and HTML editor are using WebKitGTK under the hood. I tried with webkit2gtk4.1-2.44.2-2.fc40.x86_64 and it does not exhibit the problem, while after updating to the webkit2gtk4.1-2.46.1-1.fc40.x86_64 the middle-click paste misbehaves as you described.

I'm moving this to the WebKitGTK project.

P.S.: I cannot test with the MiniBrowser, because it doesn't show the page content (with or without --editor-mode); it spams the console with `Failed to get GBM device` text.

Comment 2 pkoz 2024-10-14 08:04:47 UTC
(In reply to Milan Crha from comment #1)
> Thanks for a bug report. The plain text and HTML editor are using WebKitGTK
> under the hood. I tried with webkit2gtk4.1-2.44.2-2.fc40.x86_64 and it does
> not exhibit the problem, while after updating to the
> webkit2gtk4.1-2.46.1-1.fc40.x86_64 the middle-click paste misbehaves as you
> described.
> 
> I'm moving this to the WebKitGTK project.
> 
> P.S.: I cannot test with the MiniBrowser, because it doesn't show the page
> content (with or without --editor-mode); it spams the console with `Failed
> to get GBM device` text.

Actually, I have something other than webkit2gtk4.1:

peter@gygv ~
$ rpm -q webkitgtk4.1
package webkitgtk4.1 is not installed

peter@gygv ~
$ rpm -q webkitgtk6.0 
webkitgtk6.0-2.46.1-1.fc40.x86_64

Comment 3 Milan Crha 2024-10-14 08:29:09 UTC
> $ rpm -q webkitgtk4.1
> package webkitgtk4.1 is not installed

Typo, you missed the `2` in "the middle" of the package name.

Comment 4 pkoz 2024-10-14 08:38:08 UTC
(In reply to Milan Crha from comment #3)
> Typo, you missed the `2` in "the middle" of the package name.

That's right:

$ rpm -q webkit2gtk4.1 
webkit2gtk4.1-2.46.1-1.fc40.x86_64

Comment 5 Michael Catanzaro 2024-10-14 13:50:33 UTC
The regression is surely caused by https://commits.webkit.org/279915@main but that change isn't causing problems in other applications. Does Evolution have any special code to handle middle click paste? My best guess is you handle it in Evolution, then propagate the event instead of consume it?

Comment 6 Michael Catanzaro 2024-10-14 13:51:31 UTC
And it works fine in webkit2gtk4.1 MiniBrowser.

Comment 7 Milan Crha 2024-10-14 13:53:54 UTC
It's possible, there are some paste callbacks.

How to you differentiate paste from key press and paste from middle click and paste from menu in WebKit's JavaScript code? Those should work the same, right? I can search the code for them, if I knew how to recognize the paste with middle click.

Comment 8 Milan Crha 2024-10-14 14:18:39 UTC
I think I see the reason: Evolution's editor overrides WebKitGTK's GtkWidgetClass::button_press_event() and calls internal "<paste>" from it and then returns TRUE, to stop further processing of the signal. You broke it with the WebKitGTK change, because you moved the paste into the button-release-event, which the Evolution does not override.

I suppose you broke it, but you expect Evolution to be "fixed", right? Ideally in the way which will work for WebKitGTK both before and after your change.

The change does not break the key-press paste, because you modified only the mouse button press code.

Comment 9 Michael Catanzaro 2024-10-14 14:23:11 UTC
The easiest solution here is to just change Evolution to expect the new behavior. Nobody is going to be using newer Evolution with older WebKit, since distros update WebKit more aggressively than they update Evolution.

Comment 10 Milan Crha 2024-10-14 15:11:05 UTC
What I dislike on this the most is that you force changes in the apps, in the versions which are not supported upstream any more. There will not be any upstream releases in the versions down the road the distros update WebKitGTK for.

Anyway, this change [1] for 3.55.1+ and 3.54.1+ should help.

Fedora 41 and rawhide will wait for this Friday release, I'll do an update for the f40 and f39.

[1] https://gitlab.gnome.org/GNOME/evolution/-/commit/50096b93e7

Comment 11 Fedora Update System 2024-10-14 15:34:22 UTC
FEDORA-2024-a9cf28d697 (evolution-3.50.4-3.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a9cf28d697

Comment 12 Fedora Update System 2024-10-14 15:36:20 UTC
FEDORA-2024-cc6f922b5e (evolution-3.52.4-2.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-cc6f922b5e

Comment 13 Michael Catanzaro 2024-10-14 15:51:12 UTC
Hm, yeah, I suppose I thought this through backwards. Of course you're right: users of older Evolution will receive the bug from WebKitGTK but not the fix from Evolution.

Still, there's not a lot we can do on the WebKit side. Paste on button release is clearly better than paste on button press. We could add a quirk to change this specifically when the UI process app ID is Evolution, but I don't think it's worth it. It's much easier for distros to deploy your Evolution patch.

Comment 14 Fedora Update System 2024-10-15 02:24:21 UTC
FEDORA-2024-cc6f922b5e has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-cc6f922b5e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-cc6f922b5e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 15 Fedora Update System 2024-10-15 02:58:21 UTC
FEDORA-2024-a9cf28d697 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-a9cf28d697`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a9cf28d697

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Milan Crha 2024-10-15 07:55:29 UTC
> Paste on button release is clearly better than paste on button press.

In what precisely, please? I do not see it, I'm sorry. I do no drag with a middle button, it's probably not possible, or at least not common.

Comment 17 Michael Catanzaro 2024-10-15 14:05:27 UTC
The problem is middle mouse button is used for mouse gestures in Epiphany. If it pastes by surprise when you intend to close or refresh the page, that can leak sensitive pasteboard content to the website. Though I suppose it would probably be better to just disable middle click paste when mouse gestures are enabled.

But also: it matches every other platform. GTK is the only one doing paste on button press rather than on button release.

Comment 18 Fedora Update System 2024-10-23 01:33:43 UTC
FEDORA-2024-cc6f922b5e (evolution-3.52.4-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 19 Fedora Update System 2024-10-23 02:51:55 UTC
FEDORA-2024-a9cf28d697 (evolution-3.50.4-3.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.