It would seem this new behaviour in Chrome and also Firefox - probably making the browser more compliant with some specific - could cause issues for more many more Wicket apps than just Isis.
Does Wicket have the notion of readonly input elements rather than disabled, that we could use instead? Dan On Thu, 1 Dec 2016, 07:02 Martin Grigorov, <[email protected]> wrote: > I've played a bit with disabled input and indeed it is not possible to > select the text inside it. > Also http://getbootstrap.com/css/#forms-control-disabled (the first > caveau) > says "disables all keyboard and mouse interactions". > > Wicket sets "disabled" on FormComponents when they are "disabled in > hierarchy", so it might be more complex than just replacing > formComponent.setEnabled(false) with AttributeModifier. > > Another way to solve this is to use JS that onDomReady replaces all > "disabled" attributes with "readonly" and on form submit reverse this > operation. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Nov 30, 2016 at 2:54 PM, Dan Haywood <[email protected] > > > wrote: > > > If Martin's suggestion of using CSS doesn't sort the issue, then I guess > > the fix will need to be a little deeper.... perhaps using some other > Wicket > > API other than setDisabled(...). Maybe something like using an > > AttributeModifier to put the "readOnly" attribute on instead, cf > > http://stackoverflow.com/a/10282380/56880 > > > > On Wed, 30 Nov 2016 at 13:51 Erik de Hair <[email protected]> wrote: > > > > > > > > On 11/30/2016 01:22 PM, Dan Haywood wrote: > > > > oops. I meant https://issues.apache.org/jira/browse/ISIS-1547 > > > > > > Thanks Dan > > > > > > > > > > > > > > > On Wed, 30 Nov 2016 at 12:20 Dan Haywood < > [email protected] > > > > > > > wrote: > > > > > > > >> Thanks both. I've created > > > https://issues.apache.org/jira/browse/ISIS-1546 > > > >> > > > >> > > > >> On Wed, 30 Nov 2016 at 11:35 Martin Grigorov <[email protected]> > > > 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 < > > > >> [email protected]> > > > >> 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 <[email protected]> > 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 > > > >>>> > > > >> > > > > > > > > >
