just to say that I've raised ISIS-1552 [1] for this and it will be fixed in 1.13.2.
Thx Dan [1] https://issues.apache.org/jira/browse/ISIS-1552 On Fri, 2 Dec 2016 at 09:08 Dan Haywood <d...@haywood-associates.co.uk> wrote: > I've posted a question at us...@wicket.apache.org > > > https://lists.apache.org/thread.html/f8c956cff606d79c8a337fcf9b1b4de1e5dce71b793ebe59bdecfae7@%3Cusers.wicket.apache.org%3E > > > > On Thu, 1 Dec 2016 at 21:28 Martin Grigorov <mgrigo...@apache.org> wrote: > > On Thu, Dec 1, 2016 at 8:35 AM, Dan Haywood <d...@haywood-associates.co.uk> > wrote: > > > 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? > > > > Nope! > The only "hook" > is org.apache.wicket.markup.html.form.FormComponent#onDisabled() that > actually sets "disabled" attribute. But it is not really easy to change its > behavior globally (unless you use AOP or bytecode rewrite). > Please start a thread at Wicket mailing lists. Maybe someone else will have > a better idea how to accomplish this. > > > > > > Dan > > > > On Thu, 1 Dec 2016, 07:02 Martin Grigorov, <mgrigo...@apache.org> 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 < > > d...@haywood-associates.co.uk > > > > > > > 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 <e.deh...@pocos.nl> 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 < > > > d...@haywood-associates.co.uk > > > > > > > > > > > wrote: > > > > > > > > > > > >> 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 > > > > > >>>> > > > > > >> > > > > > > > > > > > > > > > > > > > > >
