Thanks both. I've created https://issues.apache.org/jira/browse/ISIS-1546
On Wed, 30 Nov 2016 at 11:35 Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > I guess the "disabled" attribute comes from Wicket. > If a FormComponent is setEnabled(false) then Wicket will set this attribute > to the HTML form element (input. textarea, etc.). > IMO the correct solution is to override the CSS rule that disables the > selection of the text. > > Play with > > -webkit-user-select: none; > -moz-user-select: none; > -ms-user-select: none; > user-select: none; > > Just change the value. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Nov 30, 2016 at 11:56 AM, Dan Haywood < > d...@haywood-associates.co.uk> > wrote: > > > If you are certain that using 'readonly' would do the trick, then please > > raise a ticket for that. > > Thx > > > > > > On Wed, 30 Nov 2016 at 09:44 Erik de Hair <e.deh...@pocos.nl> wrote: > > > > > Hi, > > > > > > I believe it was mentioned once in another thread that selecting text > > > (and so copying) from a disabled field doesn't work in Firefox on > > > Windows. Since a week or two it's not possible on a lot of Chrome > > > installations of our users either, probably due to a Chrome update. > This > > > really is a big problem for our users because we share a lot of > > > configuration data for internet access and telephony services and > > > copying data makes sure they don't make mistakes while configuring > their > > > systems. > > > > > > Would it be a problem to use the read only attribute instead of the > > > disabled attribute? That would be an easy fix. > > > > > > Anybody experiencing the same issue and having a nice solution? > > > > > > Erik > > > > > >
