You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Martin Grigorov <mg...@apache.org> on 2016/12/01 07:01:22 UTC
Re: Selecting text 'broken' in Chrome
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 <da...@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....@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 <dan@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 <mg...@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 <
> > >> dan@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....@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
> > >>>>
> > >>
> >
> >
>
Re: Selecting text 'broken' in Chrome
Posted by Erik de Hair <e....@pocos.nl>.
On 12/09/2016 10:28 AM, Dan Haywood wrote:
> just to say that I've raised ISIS-1552 [1] for this and it will be fixed in
> 1.13.2.
Thanks Dan!
>
> Thx
> Dan
>
> [1] https://issues.apache.org/jira/browse/ISIS-1552
>
> On Fri, 2 Dec 2016 at 09:08 Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
>> I've posted a question at users@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 <mg...@apache.org> wrote:
>>
>> On Thu, Dec 1, 2016 at 8:35 AM, Dan Haywood <da...@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, <mg...@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 <
>>> dan@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....@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 <
>>>> dan@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 <
>>> mgrigorov@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 <
>>>>>>>> dan@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....@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
>>>>>>>>>>
>>>>>>
>>
Re: Selecting text 'broken' in Chrome
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@haywood-associates.co.uk>
wrote:
> I've posted a question at users@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 <mg...@apache.org> wrote:
>
> On Thu, Dec 1, 2016 at 8:35 AM, Dan Haywood <da...@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, <mg...@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 <
> > dan@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....@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 <
> > > dan@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 <
> > mgrigorov@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 <
> > > > > >> dan@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....@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
> > > > > >>>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
>
Re: Selecting text 'broken' in Chrome
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
I've posted a question at users@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 <mg...@apache.org> wrote:
> On Thu, Dec 1, 2016 at 8:35 AM, Dan Haywood <da...@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, <mg...@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 <
> > dan@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....@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 <
> > > dan@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 <
> > mgrigorov@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 <
> > > > > >> dan@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....@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
> > > > > >>>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Selecting text 'broken' in Chrome
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Dec 1, 2016 at 8:35 AM, Dan Haywood <da...@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, <mg...@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 <
> dan@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....@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 <
> > dan@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 <
> mgrigorov@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 <
> > > > >> dan@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....@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
> > > > >>>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Selecting text 'broken' in Chrome
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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, <mg...@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 <dan@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....@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 <
> dan@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 <mg...@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 <
> > > >> dan@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....@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
> > > >>>>
> > > >>
> > >
> > >
> >
>