Impossible to copy some fields from the event view window in some cases
Categories
(Calendar :: Calendar Frontend, defect)
Tracking
(Not tracked)
People
(Reporter: bug-str, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
Click on the event to bring up the event summary pop-up.
Select a field (e.g. location) with the mouse.
Ctrl-C for copy.
Actual results:
In many cases, the [plain] text is not copied. - The paste buffer remains empty or retain the previously copied text.
(If it is a URI, then you can copy by using right-click -> "copy link")
It does not happen every time; sometimes it works. It looks like the content of the "Description" field might have some effect.
From my tests, - it looks like if there is something in "Description", and you copy that, after that you can never copy a non-URI text from the "location" field (and other fields from the upper portion of that pop-up). This might be the best recipe to reproduce it.
Observed with Thunderbird v. 91.5.0 (32-bit) on Win-10.
Expected results:
The selected text should be copied.
I am not sure if this is related to the previously fixed Bug 390753.
(The synopsis is rather different despite some similarities in the object and appearance, but the culprit might be related.)
|
||
Updated•2 years ago
|
Confirming this for TB 115.8.1 (64 bit) on Linux Mint 21.3 Cinnamon and Zorin OS 17.
If the Description field is empty, then Ctrl+C works. With some text in the Description field it fails, e. g. Strg+C does not work.
|
||
Comment 4•2 months ago
|
||
On Windows it happens all the times, as described in https://bugzilla.mozilla.org/show_bug.cgi?id=1871870
I've just tested it again (all on Win10), and I see that there is a considerable improvement in this behavior (or my computer/Windows/Thinderbird session is in such a "good" state today).
However, it seems that it depends on how the calendar is connected.
Even originally, I've seen a difference between the calendars connected using the "provider" add-on (see Bug 1762741).
Based on my today's experiments, it looks like the calendars with the read-only access and then those that have access via the "provider" add-on have more likelihood of this issue, while those connected via Google CalDAV, have less likelihood (if at all).
I suspect that there are likely some other parameters that affect this issue as well.
Description
•