There is no reason why it should be editable this is a copy only field.
current behavior is less forgiven for keyboarders (hit shift+s twice by accident)
Solution:
Add readonly attribute to field. Add css adjustment to fix cursot and background color (on chrome field turned gray and mouse cursor to no-action ready icon
Very good idea, I will do that later!
Edit: This is done. Will need to do further testing on touch devices, etc, but seems OK so far.
Edit: this checks out great on touch and mobile. Selecting the shared link is still annoying in Android (why does it deselect the selected link on tap and hold??), but at least the on screen keyboard does not pop now, so that is an improvement.
Unfortunately this has pretty bad effects on iPad (I can’t even select the URL at all now) so may need to be limited to mobile.
There are few other possible workarounds
###option 1
1.I can’t really test it on iPad, but even chrome on android presented the same issue for me,
A Textarea workaround seem to work on it, if thereported behavior in the link below is correct on iPad as well, then using the textarea trick could work on mobile safari too.
You can also try and test it pasting this executable url in the address bar of your device
open a topic
paste the following in the address bar
scroll to the bottom topic share button
you will see the share box open and the input should be selected and and selectable
I tested the following on my N4 and allowed me to select and copy, but copy button UI was not triggered by this code.
javascript:$("button[title='share a link to this topic']").click();$("#share-link div > textarea").remove();$("#share-link div > input").hide();$("#share-link div > input").before ('<textarea id="t_area_1" readonly="" style="font-size: 16px;margin-bottom: 10px;cursor: text;background-color: #fff;width: 96%;resize: none;height: 18px;white-space: nowrap;overflow: hidden;">' + $("#share-link div > input").val() + '</textarea>');setTimeout(function(){$("#t_area_1").select();},1000);
###Option 2
2.Use javascript to prevent all key press/down except: Ctrl+c Ctrl+a, Shift + left/right, left/right, home/end and Esc
instead of the css approach
I’m just reverting the change – way too dangerous for the minimal benefit of “prevents accidental keypresses” in the field. It’s really really bad on iPad.
Edit: I am also much more interested in “prevent pop of keyboard on mobile” than “whoops I pressed a key on desktop”. And all my searching indicates that is hard and error prone.
I guess a lot of this is copying something to clipboard which for security reasons, I guess, is made very difficult.
well technically mobile users are not who benefits from this feature anyway. and if there is a way to detect mobile I would recommend to disable it for mobile and leave it for desktop.
There is no issues for dekstop users.
iPad is a desktop browser to us. Non-starter. And since iPhone will have the same problem (I don’t have an iPhone to test with), means it doesn’t really work in either mobile or desktop scenarios.
This is surprisingly difficult for the reasons I documented:
Avoiding keyboard pop using HTML is really hard. (That’s the main thing I liked about this)
Copying to clipboard, even in HTML5 ultra-bleeding-2013 is not really possible.
Readonly field has seriously erratic behaviors on Mobile Safari.
Also I don’t think “disabled” is the way to go here:
a readonly element is just not editable, but gets sent when the according form submits. a disabled element isn’t editable and isn’t sent on submit. another difference is that readonly elements can be focused (and getting focused when “tabbing” through a form) while disabled elements can’t.
Readonly is correct, we want focus. If that isn’t working on iOS (and I could not do anything rational with the share link as a readonly field on iPad), that is a showstopper. Any suggested combination of Readonly and Disabled seems… bizarre.
does readonly attribute \makes any difference for keyboard pop behavior ?
yeah copy to clipboard is a pain up till recently dekstop users had to rely on flash
so I Am not surprised that there is no full support yet.
In my previous comment I was actually referring by detecting mobie to detect mobile devices. and more particualry detect devices that do not support read only input field properly.
so yes it can not be detect by the logical mobile/desktop view of discourse
Another hypothetical solution would be to use a div element.
The element can be styled to look like an input field.
with a div we can select(using JS), and it will not pop keyboard.
and as long as clicking on the link enforce a full selection of the url, it should work well.
Zeroclipboard would be a good option for this.
Github actually uses it for their “Copy to clipboard” button for repository URLs.
This may be better in a new topic, as it’s (only slightly) off topic.
I stopped reading at “invisible Adobe Flash”
@lid I like what you proposed in concept but in practice it turns out to be a minefield. I wish it wasn’t!
I understand why, but I still think that’s a short sighted choice.
it definitely does, but it also comes with side effects. The real goal is to copy the URL to the clipboard… I wonder if a plain link with instructions would work better than a textbox. How do other sites deal with this on tablet, on mobile?
What would be cool is an increase in usability
On phones we should select the text on click and trigger the copy dialog
We went a slightly different way here – on touch devices the text field containing the URL is converted to a plain hyperlink, which you can tap and hold to copy. Thanks @neil.