#37600 closed enhancement (duplicate)
Add a copy button to the Media's attachment URL field
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.5 |
Component: | Media | Keywords: | needs-patch |
Focuses: | ui, administration | Cc: |
Description (last modified by )
This proposal is to add a "copy" button to URL field in the Media attachment UI. This button makes it easier and more intuitive to copy the URL from the field. As noted, this button exists on WordPress.com and "it's quite helpful."
Note: the original iOS problem has been resolved. The revised proposal extends upon the original problem per discussions in the thread.
Attachments (2)
Change History (32)
#2
in reply to:
↑ 1
;
follow-up:
↓ 3
@
5 years ago
Replying to ocean90:
Confirmed, but the attribute is not new in trunk.
It was the version on that I've seen the bug. Someone with better knowledge of the code surely can add this info. Should I better omit the version in such cases in the future?
#3
in reply to:
↑ 2
@
5 years ago
Replying to zodiac1978:
Should I better omit the version in such cases in the future?
HI @zodiac1978 ideally the version should be set to the version the bug/feature was first introduced. It's not always possible to track that information though so in this case should be set to the version you're using. By the way "trunk" is used only to indicate a new issue on trunk, i.e. a regression. In doubt, leave empty :)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#5
@
5 years ago
- Focuses accessibility removed
Discussed this in the wpa11y bug scrub: it seems to be an iOS problem and not a WordPress problem. Therefore we removed the focus accessibility.
Related post on Stackoverflow: http://stackoverflow.com/questions/13360314/html-how-to-make-a-readonly-textarea-copyable-in-ios-devices
#6
@
5 years ago
I've read the slack log and still have no clue, why this shouldn't be a accessibility ticket. Can you please elaborate?
Even if it is an exclusive iOS problem we could provide a workaround, like a "copy to clipboard" button for example.
If we should wait for iOS to fix it, the ticket can be changed to WONTFIX, I think.
#7
@
5 years ago
- Summary changed from iOS: Readonly element URL is not selectable to iOS: Readonly attachment URL is not selectable
Removing the accessibility focus just means this issue is more related to the media component and as such should be triaged and addressed by the media component maintainers. In fact, WordPress contributions are organised in several components. It also serves the purpose to keep the accessibility tickets report we use to organise and prioritise our work as clean as possible.
That said, one member of the accessibility team volunteered to test this issue on a couple of iOS devices and will report on this ticket as soon as he has a chance.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#9
@
5 years ago
Hello, I've reviewed this using Safari on iOS devices (iPhone and iPad) as well as other browsers on iOS (Chrome) and the desktop.
The inability to select the entire text, if it overflows the field, in a disabled text input area is an iOS "feature." Since the URL value isn't editable, yet needs to be copiable, I'd recommend either:
- Adding a copy button next to or under the field like @zodiac1978 suggested, or
- Using plain text without a text field for output to the page.
For the second recommendation, the text will be selectable, as it will not overflow the container if it is allowed to wrap.
Since so many people are using mobile and iOS devices to manage their sites, this would be a nice fix/enhancement to add.
#10
@
5 years ago
- Focuses ui added
- Keywords needs-patch ui-feedback added
- Milestone changed from Awaiting Review to Future Release
- Version set to 3.5
#11
@
5 years ago
I don't know if 3kb for https://clipboardjs.com/ are too much for this little feature. Maybe we could just add it on iOS devices. This handy little script could be used to add a "copy to clipboard" button. The MIT license is GPL compatible.
Unfortunately the execCommand
which is used by the tool is not supported by iOS, so the text is just selected and has to be copied manually. :(
So maybe we should stick with plain text and maybe some button for pre-selecting the text.
ClipboardJS is using this tool from the same author: https://github.com/zenorocha/select
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
4 years ago
#13
@
4 years ago
I think adding a copy button, per @zodiac1978's suggestion, makes sense — we have that on WordPress.com and it's quite helpful. (See copy-url.png).
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
3 years ago
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
2 years ago
#17
@
2 years ago
- Keywords ui-feedback needs-design removed
copy-media-url.png is a quick mockup using a "small" version of our core secondary button; it's inset 2px from the edges of the field, and the text size is decreased from 13px to 12px.
#20
follow-up:
↓ 21
@
2 years ago
See also this related comment: https://core.trac.wordpress.org/ticket/41612#comment:48
I wouldn't be opposed to experiment a "copy" button: it could help to clarify the UI. Also, at that point maybe there wouldn't be the need to put these URLs within a readonly input field. It could be just text.
#21
in reply to:
↑ 20
@
2 years ago
Replying to afercia:
See also this related comment: https://core.trac.wordpress.org/ticket/41612#comment:48
I wouldn't be opposed to experiment a "copy" button: it could help to clarify the UI. Also, at that point maybe there wouldn't be the need to put these URLs within a readonly input field. It could be just text.
I would try to write a patch for this, but if we end up with using a plain text input I would rather skip that. Especially because iOS seems to have this fixed in the meantime. It is still not very easy, but at least it is now possible to select the whole text.
I've checked on my WordPress.com account. They are using clipboardjs.
Maybe someone from the component maintainers can chime in to finally make a decision.
#23
follow-up:
↓ 24
@
2 years ago
Especially because iOS seems to have this fixed in the meantime.
Just to clarify, @zodiac1978, do you mean that selection of the current field's contents works correctly in iOS now?
#24
in reply to:
↑ 23
@
2 years ago
Replying to mikeschroder:
Especially because iOS seems to have this fixed in the meantime.
Just to clarify, @zodiac1978, do you mean that selection of the current field's contents works correctly in iOS now?
Depends on the definition of „correctly“ in this case. I tested it with recent stable iOS 12.4.1.
And I could select the whole field/text. It is not easy and intuitive, but possible now.
A „Copy URL“ would be more easy for beginners and a normal text field like suggested from @afercia would be more accessible. So we need a decision which path we should follow I think.
Any recommendations?
#25
follow-up:
↓ 26
@
2 years ago
I think a copy button makes sense! I've heard from users that the field is used often, and it sounds helpful.
Wondering if, since the text is selectable now, it would make sense to change this to an enhancement, since the initial bug is fixed?
#26
in reply to:
↑ 25
@
2 years ago
- Type changed from defect (bug) to enhancement
Replying to mikeschroder:
I think a copy button makes sense! I've heard from users that the field is used often, and it sounds helpful.
Wondering if, since the text is selectable now, it would make sense to change this to an enhancement, since the initial bug is fixed?
Great! I think we can change to enhancement then.
I will try to write a patch for it.
This ticket was mentioned in Slack in #core-media by a223123131. View the logs.
10 months ago
#28
@
9 months ago
- Description modified (diff)
- Keywords dev-feedback removed
- Summary changed from iOS: Readonly attachment URL is not selectable to Add a copy button to the Media's attachment URL field
@zodiac1978 I modified the title and description to convert the ticket from the original reported iOS issue to the new "add a button" proposal. Please review and revise accordingly.
Confirmed, but the attribute is not new in trunk.