Home › Forums › Classic DFFS › Users unable to copy and paste text from multiline field set to read only
- This topic has 7 replies, 2 voices, and was last updated 2 years, 10 months ago by
Alexander Bautz.
-
AuthorPosts
-
-
October 28, 2021 at 16:24 #34943
Hi Alexander, the team reported another issue to me today. I have replicated the problem and tried different browsers, and am having the same issue.
When a multiline text field is set to read only, users are unable to successfully copy and paste. My team uses this to copy notes made and paste into outlook for reference in an email, things like that.
Not sure what can even be done about this. Previously users had an issue where if they pasted into an enhanced rich text, it pasted the entire html of the form, which caused a bug. I definitely don’t want to re-introduce that problem lol.
Anyway, here’s a screenshot example. When I try to copy this, I can highlight and copy, but it doesn’t actually go to clipboard. Nothing ever pastes.
Attachments:
-
October 28, 2021 at 18:01 #34952
I’m not able to recreate this issue – which version of DFFS are you running in this form? – I did fix a similar issue in v4.4.5.5 back in August 08, 2020: https://spjsblog.com/dffs/dffs-change-log/#DFFS_v4455
Alexander
-
October 29, 2021 at 14:53 #34964
SharePoint Online
Version information
DFFS Loader: v2
DFFS frontend: 4.4.5.34 – October 15, 2021
DFFS frontend CSS: 4.64 /
Autocomplete: 1.6.52 – April 25, 2021
Cascading dropdowns: 3.7.48 – September 22, 2021
jQuery: 1.12.4
Lookup: 1.1.20 – March 10, 2020
Resource management: 2.4.5 – August 29, 2019
SPJS-Utility: 1.354 – October 15, 2021
vLookup: 2.2.162 – October 12, 2021One thing I noticed, I copied some text from a different source, and then tried to copy the text from the multiline and paste it, and it pasted what I copied from the other source. So whatever it is, the copy within DFFS is never reaching the clipboard since it’s not overwriting what I copied previously.
Also, just out of curiosity, the version you referenced the fix was in is 4.4.5.5, so why is the October 15 2021 version a lower number at 4.4.5.34?
-
This reply was modified 2 years, 10 months ago by
Travis Goodman.
-
This reply was modified 2 years, 10 months ago by
Travis Goodman.
-
This reply was modified 2 years, 10 months ago by
-
-
October 29, 2021 at 15:40 #34974
Looking at it closer it seems the fix no longer works – I’ll get it re-fixed and release a new version during the weekend.
You should be able to fix it in your form by adding this code in your Custom JS:
jQspjs("#dffs_YOUR_FIELD_NAME td.ms-formbody").on("mouseup copy", function (event) { if (jQspjs(event.target).parents(".dffs-readonly-inner").length > 0) { event.stopPropagation(); } });
Replace YOUR_FIELD_NAME with the actual internal name of your field.
The last digit in the number is not read as 50, but as 5 – so 34 is bigger…
Alexander
-
October 29, 2021 at 18:00 #34978
Oh, duh. Now that I’ve had my morning coffee, that makes total sense lol. Visually seeing it at first looked funny.
-
-
October 31, 2021 at 08:28 #34988
I have published an update to fix this issue – let me know how it works out.
https://spjsblog.com/2021/10/31/dffs-package-updated-to-v4-4-5-35/
Alexander
-
November 3, 2021 at 17:00 #35024
That did the trick! Thanks as always.
-
-
November 3, 2021 at 17:30 #35030
Thanks for the feedback.
Alexander
-
-
AuthorPosts
- You must be logged in to reply to this topic.