Description of problem: Please note, this may not be an Evo bug at all, as it appears to happen only under Wayland. Anyhow... Problem 1: Right click on a link inside an email brings up a context menu, but the menu box contains only two options (open and copy) up the top of the box. There are about 10 empty lines below those two. Problem 2: If I select Copy Link Location and try to paste it into Firefox, there will be a slight delay and then usually nothing happens (i.e. the text is not pasted into the address box of FF). Journal has things like: Nov 15 11:14:59 shrek.rexursive.com evolution[10057]: Error writing selection data: Error writing to file descriptor: Broken pipe Occasionally, pasting the text works into terminal, for instance. Version-Release number of selected component (if applicable): evolution-3.22.1-2.fc25.x86_64 How reproducible: Always for context menu. Most of the time for copy/paste. Steps to Reproduce: 1. See description. Actual results: Context menu appears incorrect. Copy paste doesn't work. Expected results: This worked in F24. Additional info: I run Evo under Xvnc on another machine as well and have none of these problem. I am not quite sure whether this copy/paste problem is limited to Evo or not, but it is Wayland specific. So, as I said above, it may not be an Evo bug at all. No idea.
Thanks for a bug report. If I'm not mistaken (and my information outdated), the issue is in the webkitgtk4. Could you try the same with /usr/libexec/webkit2gtk-4.0/MiniBrowser please? This applies to the 2) at least. The 1) can be an evolution issue.
(In reply to Milan Crha from comment #1) > Thanks for a bug report. If I'm not mistaken (and my information outdated), > the issue is in the webkitgtk4. Could you try the same with > /usr/libexec/webkit2gtk-4.0/MiniBrowser > please? This applies to the 2) at least. The 1) can be an evolution issue. Copy/paste seems to work more consistently with that browser from Evo (haven't had one failure). I just tried a few URLs and sometimes it even works with FF, but many times it won't. The problem is especially obvious into private FF windows. If it matters, I'm running FF with Electrolysis on. As for issue 1, I keep up to date with updates-testing and I often reboot and I cannot see the issue with the menu right now. So, maybe something else fixed that - no idea.
(In reply to Bojan Smojver from comment #2) > As for issue 1, I keep up to date with updates-testing and I often reboot > and I cannot see the issue with the menu right now. So, maybe something else > fixed that - no idea. This is back again, but there is a bit more to it. The problems with context menus manifest themselves for email links as well. However, it's not that the menu is always too big for the number of items in it. Sometimes, the menu is too small and one has to scroll up/down to see everything, although there is plenty of pixels on the screen to display everything (e.g. there are about 8 items to display, but menu is only 2 or 3 items tall).
I can confirm both issues as I see them on my box as well. The second one is a WebKitGTK+ bug (I will later add attach an upstream bug number here) which is also reproducible with Epiphany. The first one is probably Evolution's bug as we are creating the context menu.
(In reply to Bojan Smojver from comment #0) > Right click on a link inside an email brings up a context menu, but the menu > box contains only two options (open and copy) up the top of the box. There > are about 10 empty lines below those two. My personal theory is that the menu itself is somehow reused, but it is shown before the right items are shown (and all other hidden), thus they cause this misbehaviour. I think it's the reason why on Xorg the menu is mispositioned - the "empty" items get hidden, but only after the menu itself is shown.
(In reply to Milan Crha from comment #5) > My personal theory is that the menu itself is somehow reused, but it is > shown before the right items are shown (and all other hidden), thus they > cause this misbehaviour. I think it's the reason why on Xorg the menu is > mispositioned - the "empty" items get hidden, but only after the menu itself > is shown. You are probably right. I actually can see a similar behavior in Nautilus as well. I asked the Wayland devs about it.
The evolution's issue is the asynchronous nature of EWebView's web_view_update_actions() due to webkit_web_view_can_execute_editing_command() usage. When I reorder the callback code back to the web_view_update_actions(), then it behaves better, but only until I have anything selected in the web view. In that case the "Copy" item shows up, but again too late and there is a scrolling in the popup menu, which is odd and wrong at the same time. The thing is that the e_web_view_update_actions() (similarly to any other "update-actions") is required to be synchronous, thus when the menu is pop up, the items in it are already shown/hidden as they should be. I do not know whether there is any replacement for the webkit_web_view_can_execute_editing_command(), like on the web-extension side, to provide our own property in our extension, similar to "NeedInput", but this time for the editing commands (cut/copy/paste). It could be an unsigned integer, a bit-or of can_cut, can_copy, can_paste.
Fixed with upstream commit [0] that will be included in the next 3.22.3 release of Evolution. [0] - https://git.gnome.org/browse/evolution/commit/?id=ba1f878
(In reply to Tomas Popela from comment #8) > Fixed with upstream commit [0] that will be included in the next 3.22.3 > release of Evolution. > > [0] - https://git.gnome.org/browse/evolution/commit/?id=ba1f878 Thank you!