Cannot paste text from Terminology to FeatherPad

[Peter2121]

FeatherPad 1.3.4 on FreeBSD 13.1-RELEASE-p3 (x64), installed from package (built with Qt5).
It is impossible to paste text from Terminology 1.12.1 (EFL based terminal) - nothing happens in FeatherPad.
It was working before the last update of packages (sorry, I have not noted the previous versions of Terminology and FeatherPad).
No problems to paste the same text from Terminology to another editors (tested with Leafpad and Xfw).
No problems to paste the same text from other terminal to FeatherPad (tested with Qterminal).

I'm ready to help to debug it, but I have no idea where to search the problem.

[tsujan]

Not reproducible with Terminology 1.13.0. Texts that are copied from Terminology are pasted into FeatherPad correctly.

Please note that the source of the copied text doesn't make any difference to FeatherPad.

The info you provided was minimal. Against which version of Qt your installed FeatherPad is compiled? Qt5 or Qt6?

[tsujan]

Oh, sorry, you'd written in parentheses that it was built against Qt5.

Can you paste from Terminology into another Qt5 app?

[Peter2121]

Yes, I can paste from Terminology into QTerminal.

[tsujan]

There are two methods of copying text from Terminology: (1) Just by selecting text:

---

---

In this case, the selected text is pasted into FeatherPad by pressing the middle mouse button.

Or (2) by selecting text, right clicking the selection and pressing "Copy"

---

---

In this case the text can be pasted with Ctrl+V or through right click menu.

Do you use another method?

[Peter2121]

1. I've just tested with terminology 1.13 - the same thing
2. I always use (2) method with Ctrl-V. If I try right click menu in FeatherPad - the Paste option is grayed out (after Copy in Terminology).
3. The current version of Qt is 5.15.7.
4. I've just tested in VLC - no problems with paste from Terminology.
5. The version of FeatherPad before upgrade (was correctly working) was 1.2.0, the version of Qt was 5.15.5

[tsujan]

The version of FeatherPad before upgrade (was correctly working) was 1.2.0

Since V1.3.3, FeatherPad consults QMimeData::hasText() to know if there's any plain text in the clipboard contents. That's important for preventing problems. Most Qt apps may not do it.

My guess is that, in your case, Terminology doesn't announce that it has given plain text to the clipboard, in which case, FeatherPad ignores it.

If I try right click menu in FeatherPad - the Paste option is grayed out

Exactly because the existence of plain text isn't announced by the source.

However, it's still a mystery why Terminology 1.13.0 behaves differently for us.

Would you please answer another question? What happens when you paste the text from Terminology into the search entry of FeatherPad or another Qt5 app?

[Peter2121]

I've just built the release 1.2.0 with the current version of Qt - there is NO problem here.
I can paste correctly the text from Terminology into the search entry of FeatherPad 1.3.4.

I think that the idea of ignoring clipboard content if the mime type is not set - it is not genial. I would suggest to ignore the content if the mime type is SET to something unknown (like images).
BTW, another EFL-based software (Ecrire editor) has the same issue - I cannot paste the text copied from Ecrire into FeatherPad.
Anyway, I will try to contact EFL dev team to inform them about this issue (could you reopen it, please?)

[tsujan]

There's a simple workaround for such rare cases but, unfortunately, it isn't resource-friendly, especially when the clipboard contains a huge amount of text.

IMHO, the problem should be fixed in Terminology: like other apps, it should inform the clipboard about text/plain.

Anyway, I will try to contact EFL dev team to inform them about this issue

The problem is that, like me, they may not be able to reproduce it ;) Some piece of info is definitely missing. We still don't know why pasting has no problem in my case (the reason I closed the issue), while it's impossible in your case.

[Peter2121]

Is there any tool that could show if the mime type for clipboard data is set or not?
When you cannot reproduce the bug - it does not mean that it does not exist ;)
If you think that the mime type is so important for the data to paste into the document body - why don't you check it on pasting into the search area?

[tsujan]

Is there any tool that could show if the mime type for clipboard data is set or not?

I don't know of any tool other than a code (QMimeData::hasText() with a Qt code, for instance).

When you cannot reproduce the bug - it does not mean that it does not exist ;)

Of course! But, within rational boundaries, my diagnosis is that the problem isn't in FeatherPad. FeatherPad should only accept plain text. Even if the text is text/html, it should also be available as text/plain — as it is here.

If you think that the mime type is so important for the data to paste into the document body - why don't you check it on pasting into the search area?

That's up to Qt. Problems aren't rare in a big toolkit like Qt, and I only circumvent those issues that are important — there are many workarounds for important Qt bugs in the code.

[tsujan]

Problem solved! I was under Wayland (Wayfire), where there was no problem (probably, Wayfire's clipboard management circumvented the issue). When I logged into an X11 environment, the problem showed up.

Under X11, Terminology gives text/plain;charset=utf-8 as the MiIME type (or, at least, Qt sees it as such), which is wrong — it should have been text/plain.

Adding a workaround for a weird case like this is not an option. The issue should be reported to Terminology.

EDIT: If you see the issue with other EFL-based apps, it should be in EFL itself.

[Peter2121]

Under X11, Terminology gives text/plain;charset=utf-8 as the MiIME type (or, at least, Qt sees it as such), which is wrong — it should have been text/plain.

Please, could you provide any reference to a document where EFL devs could see that text/plain;charset=utf-8 as the MiIME type is wrong? I definitely need it to open a ticket. And yes, the problem is at EFL level, not at the level of apps (this is a good thing though).

[tsujan]

https://datatracker.ietf.org/doc/html/rfc6838 was the only reference that I found about "charset". A quotation from there:

If a "charset" parameter is specified, it SHOULD be a required
parameter, eliminating the options of specifying a default value.  If
there is a strong reason for the parameter to be optional despite
this advice, each subtype MAY specify its own default value, or
alternatively, it MAY specify that there is no default value.
Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the
default.  See [RFC6657] for additional information on the use of
"charset" parameters in conjunction with subtypes of text.

Now, we can waste time by giving different interpretations of the above text; or we can simply stick with text/plain, as in any normal app.

P.S. I could bypass Qt and include text/plain;charset=utf-8 but, really, wouldn't it be weird?

[tsujan]

I definitely need it to open a ticket...

If you do so, please tell them that QMimeData::hasText() returns false because the format is received as text/plain;charset=utf-8, not as text/plain.

It'll be a dead-end if they reply that Qt should recognize text/plain;charset=utf-8 as plain text ;)

[Peter2121]

I suppose that the presence of the charset parameter is not accidental here. I know that the development of EFL is sponsored by Samsung (as EFL is the base library for Tizen). So, it is highly probable that there were some issues with text encoding in different scenarios/applications. So, very likely, the ticket will be refused at EFL level.

I would advise you to analyze the MIME type in FeatherPad, bypassing QMimeData::hasText(), and accept text/plain;charset=* (or even better - accept text/plain*).

...and yes, if I indicate in EFL ticket that QMimeData::hasText() returns false - they will propose to open a ticket at Qt level ;)

Anyway, I solved this problem for me patching FeatherPad ;)

[tsujan]

suppose that the presence of the charset parameter is not accidental here.

Probably. But, at least, text/plain could have been added too.

I would advise you to analyze the MIME type in FeatherPad

Yes, but it would feel weird just for this case. Moreover, I'm not sure that EFL doesn't give an empty text with text/plain;charset=utf-8 — I have my reasons not to trust it.

Anyway, I solved this problem for me patching FeatherPad ;)

I hope you haven't removed if (source->hasText()) (see 39f7040).

Accepting text/plain;charset= is the best workaround. Checking QMimeData::text() for emptiness is another method, but it isn't resource-friendly with huge texts.

[tsujan]

I saw that Qt itself made use of !QMimeData::text().isEmpty(); so the "resource-friendly" argument wasn't valid. Since I can tolerate a little weirdness, I added c38c606

[Peter2121]

Cool!! Thanks!!

I created a ticket at EFL: https://git.enlightenment.org/enlightenment/efl/issues/18

[tsujan]

I created a ticket at EFL

Good :)

The workaround doesn't seem to have a cost for us (I tested with a huge text). It also covers the nonexistent case of not respecting the lower-case rule ;)