When you git Ctrl+V with focus on an inline composer, the composer's paste handler is not being called.  (It is being called through the context menu.)  Instead, something else is handling the paste for us.  I can't find any other paste handler we have, so it must be some default handler in GTK or WebKit.

Confirming in 0.6.1. This is a bad one, IMO.

Just hit this again on latest master build.  I see that when I hit Ctrl+V I get the same result I get with right-click and paste formatted: it's used the first item copied to clipboard. If you copy other text, Ctrl+V keeps pasting the first item.
The right paste - the last copied item - works only if I right-click and paste.

I agree that it's a bad one (even if there's a workaround).

Robert, attached is a diff that explores this problem.  Maybe you have some thoughts on this.  There's two aspects to it:

* I added some debug to determine when a few of our editing keyboard handlers are being invoked (i.e. paste, paste with formatting, and, importantly, on_action).

* There's commented-out code that "fixes" this bug by intercepting Ctrl+V and redirecting it to our paste handler.

The second, of course, is a hack and merely works around the problem.

What's interesting to me is that with this code commented out, on_action() is invoked when Ctrl+V is pressed.  I suspect this is the core of the problem, but I don't know why this occurs.  Can you investigate?

Created attachment 280753 [details] [review]
Test patch investigating problem

I'm not seeing the on_action handler being fired for Ctrl+V.

Somehow, WebViews have built-in paste capability.  If I don't do anything with accelerators, Ctrl+V works all by itself.  I don't know if this happens entirely within the WebView, or if the Gtk.Window has the keybinding and dispatches a paste-clipboard event to the WebView.  Either way, I think this is what's being triggered in the inline mode, instead of the accelerator we provide.

Either way, we ought to be able to get inside of this and provide custom paste handling for the WebView.  I haven't figured out how to do this yet (though I have it working for a Gtk.Entry).

But this isn't how the composer works.  For reasons I don't understand, instead of relying on the natural handling of paste events, we try to catch the Ctrl+V event and dispatch it ourselves.  This seems silly to me.  We also do this to cut and copy, without even changing the behavior in any case.  I don't understand this at all!

I noticed that too while building the patch.  I even ripped out the paste action handler and paste still worked.

I wish I could explain why we do that; I'd have to dig through the commit logs to find why.  (I did very little work on the composer, esp. early on.)  I wonder if that was to work around problems with earlier versions of WebKit that have been fixed in later releases.

Unfortunately, though, even with the paste code ripped out (or, at least, partially ripped out) the problem remained.  It is tempting to clean up that code, for no other reason than the composer is complicated enough as-is.  But I am concerned about regressions.  It may be there's a particular use case that code is solving, but I can't be certain.

As far as on_action, be sure you have formatted text in the clipboard (I use LibreOffice Writer) when you do a Ctrl+V.  The last debug you'll see is on_action.  However, I just now noticed that it's only being called the first time you Ctrl+V with a composer.  Thereafter, it doesn't fire without creating a new inline composer.  Strange.

I've already spent some time trying to track things down with git blame.  It's a bit confused by the recent renaming, so I'll share what I know so far.

The on_cut(), on_copy(), and on_paste() methods were added to the composer in 459af216. which introduced HTML composition.  These just trigger the editor's methods, though, so it's hard for me to believe they're working around anything.

Shortly thereafter, 0793679d added unformatted pasting, but didn't do anything to the cut or copy commands.

A bit later, ad6b1829 fixed bug #713369, making the cut, copy, and paste commands work on the right elements.  I assume this problem had been introduced by 459af216.

I'll asking on the WebkitGTK list about custom paste actions.  I bet right now we're running the built-in actions for cut and copy sometimes and the ones we provide other times.  We just don't notice because they're doing the same things.  I'd feel much more secure in the future if we can just get inside the built-in ones and always use those.

I think you're on the right track.  Why the handlers were added for HTML composition I don't know; that was added late in the first cycle (Geary just did plain text, but I can't believe cut/copy/paste didn't work before then).

It does look like our handlers are running some times and WebKit's are running other times.  Let me know what the WebKit guys say.

Flipping through git commits, it seems the custom cut/copy/paste handlers had two real-world uses over the years:

1. Handle our custom context menu that we used in place of WebKit's default.
2. Tackling the focus issue as Robert pointed out above.

But there's a part of history that you probably won't find in git.  When I originally built the composer UI, I created a toolbar that had a button for just about everything, including (you guessed it!) cut, copy, and paste.

The prototype design was considered too complex, so we started removing things.  The clipboard buttons were early victims.  Of course, just because I removed the buttons doesn't mean I removed the associated actions.  I doubt I even considered that!


Eric Gregory
Geary Developer Emeritus

Ok, so that solves that mystery.  We could consider ripping out those actions entirely.  I recall circumventing the actions and not actually solving this problem w/ paste-formatted, but removing them would at least help simplify the composer code.

Thanks for the info, Eric.  I haven't heard back on the webkitGTK list yet.  Hopefully we'll get something useful, and we can get rid of the cut, copy, and paste actions.  We will have to figure out what to do about the context menu then.  And I fully expect to uncover another two or three things that the actions do for us.

Any update on this issue?

I never got a reply from the webkit folks, I'm afraid.

I'll admit that I work in plain text mode and use middle-button paste, so I completely avoid this bug in my day-to-day life.

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

Adding it here so it doesn't get lost.

In the mailing list we discussed a different but related bug. Paste with formatting doesn't work when copied from Firefox, as you can see here:
https://mail.gnome.org/archives/geary-list/2015-May/msg00009.html

Comment by Robert:

"I see the same thing. It's not the same as 730495, but I suspect it has the same root cause: we're relying on WebKit to handle copy-and-paste operations, and it doesn't always do what we want it to.


During a copy-and-paste operation, the source and sink have to agree on a data format that they both support. I suspect that Firefox and Chrome offer different rich text formats. Since Chrome is related to WebKit, they can agree on a rich text format for the paste. However, Firefox and WebKit can't agree, and so we fall back to plain text.


I'm a bit surprised by this, honestly. I'd have thought that both would just use HTML as their rich text format. I guess that would have been too sensible. "

When I paste using ctrl-v, I get the formatted text.  When I paste by right-clicking and choosing "Paste," I get the un-formatted text.

0.11.2-1~xenial1

(In reply to Ken Berland from comment #17)
> When I paste using ctrl-v, I get the formatted text.  When I paste by
> right-clicking and choosing "Paste," I get the un-formatted text.
> 
> 0.11.2-1~xenial1

This is expected behaviour. If you want formatted text, you should use 'Paste with Formatting' in the right-click menu (this option is only shown in 'Rich Text'-mode).

That doesn't make sense for two reasons:

1) The right-click action is marked with a keyboard shortcut that yields a different result.  See image.

2) There's no keyboard shortcut to paste without formatting.

Created attachment 339198 [details]
Menu and keyboard shortcut mismatch

Adding a dependency on the WebKit2 port since the current behaviour may change when that lands.

So I'm not pretty sure this is caused by the hack needed to support single keystroke commands as outlined in Bug 778738 - at the moment since widgets are allowed to process key press events before the keyboard shortcut machinery, WebKit's paste handler is invoked for Ctrl+V before Geary's is. Since Geary defaults to pasting plain text and WK defaults to pasting rich text, we get different behaviour using the context menu and keyboard shortcuts when the composer's editor is focused.

Fixing Bug 778738 should automatically fix this.

"So I'm /now/ pretty sure"

Is there a timeframe for this? Don't want to be a bother, but I've been working around this bug for close to three years now and it's a bit silly...

I'm hoping to get the underlying cause (Bug 778738) fixed for 0.13, which will hopefully be out sometime before the end of the year, if that helps? :)

Patches for that bug gratefully appreciated, of course!

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

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

I was prompted to have a look at this again the other day, and realised there's a pretty straight-forward workaround to fix this before having to go to all the work for Bug 778738. That has been pushed to master in commit 0b57e5b4, and I will merge it to 0.12 after it gets a bit of testing.

Mike,  I confirm that it works fine now.

About comment #16, should I add a new issue for formatted copy&paste from Firefox?

Hey Federico, sorry I missed your comment.

Firefox rich text paste is definitely a separate issue, so if you can open a new one for it that would be great. There might be some things we can look at to convince WebKitGTK to paste rich text from FF.

Added here: https://gitlab.gnome.org/GNOME/geary/issues/117