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
> > > > >>>>
> > > > >>
> > > >
> > > >
> > >
> >
>

Reply via email to