Re: Issues with wicket-contrib-input-events in Mozilla
Hehe, great :) So no problems after all?
2009/1/29 dukejansen
>
> Okay, nevermind. It turns out the issue can be corrected much more simply,
> by
> using an "onclick" event type instead of a "click" event type, which
> arguably may have been obvious.
>
> I'm still not certain whether this will still work properly for
> AjaxFallbackLinks or other links that have both an onclick AND an href, but
> I believe for most/all of my use cases, that's not an issue...
>
> -Jason
>
>
> dukejansen wrote:
> >
> > The code I posted below actually doesn't even get called if the tag has
> an
> > onclick attribute...
> >
> > I'm working up a workaround now, I'll post it if it ends up working...
> >
> > -Jason
> >
> >
> > dukejansen wrote:
> >>
> >> Nino,
> >>
> >> Thanks for the quick reply...
> >>
> >> I dug a bit deeper and you are correct, it does have some hooks for
> >> handling Links, but it may only work for links which extend from the
> base
> >> Link class.
> >>
> >> // Try to bind to link so shortcut will work.
> Should only be done if
> >> // no other handlers were found
> >> if (component instanceof Link && eventType == null)
> {
> >> linkUnbound = true;
> >> return;
> >> }
> >>
> >> In my case, the link is an Ajax link which launches a Modal, and
> AjaxLink
> >> does not extend Link. Furthermore, the behavior of simply handling the
> >> link by calling location = href is not necessarily sufficient - I
> believe
> >> this would circumvent any onclick event handlers set on the tag, which
> >> would prevent the AjaxLink from working...
> >>
> >> I'm thinking the hook for ajax links probably needs to be something like
> >> a combination of the two mechanisms - instead of trying to call click(),
> >> which doesn't exist, would need to call the onclick() directly, and then
> >> check it's result and if true follow the link, if false do not... that
> >> way it could still handle the ajax fallback links as well, I believe.
> >>
> >> This is all theory, haven't actually verified any of this would work
> >> yet...
> >>
> >> On top of all this, I'm working with a 1.4 backport we made of the
> >> input-events code, so any fix I come up with will likely not make it
> back
> >> into the main trunk for the input-events module...
> >>
> >> -Jason
> >>
> >>
> >> Nino Martinez-2 wrote:
> >>>
> >>> I cant exactly remember what the scope where, just that it did support
> >>> links at some point, in safari and IE. Patches are always welcome..
> >>>
> >>> But looking in the source there are some auto hooking for links
> >>> actually, which uses href instead of click AFAIR it should just pick it
> >>> up automaticly...:
> >>>
> >>>
> >>> function init${wicketComponentId}() {
> >>> shortcut.add("${keys}",function() {
> >>>
> >>>
> >>> window.location=document.getElementById('${wicketComponentId}').href;
> >>>
> >>> },{
> >>> 'disable_in_input':${disable_in_input},
> >>> 'type':'${type}',
> >>> 'propagate':${propagate},
> >>> 'target':${target}
> >>>
> >>> });
> >>> }
> >>> init${wicketComponentId}();
> >>>
> >>>
> >>> Did you check the examples, and see if they still are working, they do
> >>> include a link aswell?
> >>>
> >>>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21732972.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Issues with wicket-contrib-input-events in Mozilla
Okay, nevermind. It turns out the issue can be corrected much more simply, by
using an "onclick" event type instead of a "click" event type, which
arguably may have been obvious.
I'm still not certain whether this will still work properly for
AjaxFallbackLinks or other links that have both an onclick AND an href, but
I believe for most/all of my use cases, that's not an issue...
-Jason
dukejansen wrote:
>
> The code I posted below actually doesn't even get called if the tag has an
> onclick attribute...
>
> I'm working up a workaround now, I'll post it if it ends up working...
>
> -Jason
>
>
> dukejansen wrote:
>>
>> Nino,
>>
>> Thanks for the quick reply...
>>
>> I dug a bit deeper and you are correct, it does have some hooks for
>> handling Links, but it may only work for links which extend from the base
>> Link class.
>>
>> // Try to bind to link so shortcut will work. Should
>> only be done if
>> // no other handlers were found
>> if (component instanceof Link && eventType == null) {
>> linkUnbound = true;
>> return;
>> }
>>
>> In my case, the link is an Ajax link which launches a Modal, and AjaxLink
>> does not extend Link. Furthermore, the behavior of simply handling the
>> link by calling location = href is not necessarily sufficient - I believe
>> this would circumvent any onclick event handlers set on the tag, which
>> would prevent the AjaxLink from working...
>>
>> I'm thinking the hook for ajax links probably needs to be something like
>> a combination of the two mechanisms - instead of trying to call click(),
>> which doesn't exist, would need to call the onclick() directly, and then
>> check it's result and if true follow the link, if false do not... that
>> way it could still handle the ajax fallback links as well, I believe.
>>
>> This is all theory, haven't actually verified any of this would work
>> yet...
>>
>> On top of all this, I'm working with a 1.4 backport we made of the
>> input-events code, so any fix I come up with will likely not make it back
>> into the main trunk for the input-events module...
>>
>> -Jason
>>
>>
>> Nino Martinez-2 wrote:
>>>
>>> I cant exactly remember what the scope where, just that it did support
>>> links at some point, in safari and IE. Patches are always welcome..
>>>
>>> But looking in the source there are some auto hooking for links
>>> actually, which uses href instead of click AFAIR it should just pick it
>>> up automaticly...:
>>>
>>>
>>> function init${wicketComponentId}() {
>>> shortcut.add("${keys}",function() {
>>>
>>>
>>> window.location=document.getElementById('${wicketComponentId}').href;
>>>
>>> },{
>>> 'disable_in_input':${disable_in_input},
>>> 'type':'${type}',
>>> 'propagate':${propagate},
>>> 'target':${target}
>>>
>>> });
>>> }
>>> init${wicketComponentId}();
>>>
>>>
>>> Did you check the examples, and see if they still are working, they do
>>> include a link aswell?
>>>
>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21732972.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Issues with wicket-contrib-input-events in Mozilla
Ahh ok, it would be very nice if there could be a patch somehow on this..
BTW the auto hook is extremely simple.. So it will only auto hook in the
most simple cases, you can always override, and manually tell it what todo..
2009/1/29 dukejansen
>
> The code I posted below actually doesn't even get called if the tag has an
> onclick attribute...
>
> I'm working up a workaround now, I'll post it if it ends up working...
>
> -Jason
>
>
> dukejansen wrote:
> >
> > Nino,
> >
> > Thanks for the quick reply...
> >
> > I dug a bit deeper and you are correct, it does have some hooks for
> > handling Links, but it may only work for links which extend from the base
> > Link class.
> >
> > // Try to bind to link so shortcut will work.
> Should only be done if
> > // no other handlers were found
> > if (component instanceof Link && eventType == null)
> {
> > linkUnbound = true;
> > return;
> > }
> >
> > In my case, the link is an Ajax link which launches a Modal, and AjaxLink
> > does not extend Link. Furthermore, the behavior of simply handling the
> > link by calling location = href is not necessarily sufficient - I believe
> > this would circumvent any onclick event handlers set on the tag, which
> > would prevent the AjaxLink from working...
> >
> > I'm thinking the hook for ajax links probably needs to be something like
> a
> > combination of the two mechanisms - instead of trying to call click(),
> > which doesn't exist, would need to call the onclick() directly, and then
> > check it's result and if true follow the link, if false do not... that
> way
> > it could still handle the ajax fallback links as well, I believe.
> >
> > This is all theory, haven't actually verified any of this would work
> > yet...
> >
> > On top of all this, I'm working with a 1.4 backport we made of the
> > input-events code, so any fix I come up with will likely not make it back
> > into the main trunk for the input-events module...
> >
> > -Jason
> >
> >
> > Nino Martinez-2 wrote:
> >>
> >> I cant exactly remember what the scope where, just that it did support
> >> links at some point, in safari and IE. Patches are always welcome..
> >>
> >> But looking in the source there are some auto hooking for links
> >> actually, which uses href instead of click AFAIR it should just pick it
> >> up automaticly...:
> >>
> >>
> >> function init${wicketComponentId}() {
> >> shortcut.add("${keys}",function() {
> >>
> >>
> >> window.location=document.getElementById('${wicketComponentId}').href;
> >>
> >> },{
> >> 'disable_in_input':${disable_in_input},
> >> 'type':'${type}',
> >> 'propagate':${propagate},
> >> 'target':${target}
> >>
> >> });
> >> }
> >> init${wicketComponentId}();
> >>
> >>
> >> Did you check the examples, and see if they still are working, they do
> >> include a link aswell?
> >>
> >>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21732636.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Issues with wicket-contrib-input-events in Mozilla
The code I posted below actually doesn't even get called if the tag has an
onclick attribute...
I'm working up a workaround now, I'll post it if it ends up working...
-Jason
dukejansen wrote:
>
> Nino,
>
> Thanks for the quick reply...
>
> I dug a bit deeper and you are correct, it does have some hooks for
> handling Links, but it may only work for links which extend from the base
> Link class.
>
> // Try to bind to link so shortcut will work. Should
> only be done if
> // no other handlers were found
> if (component instanceof Link && eventType == null) {
> linkUnbound = true;
> return;
> }
>
> In my case, the link is an Ajax link which launches a Modal, and AjaxLink
> does not extend Link. Furthermore, the behavior of simply handling the
> link by calling location = href is not necessarily sufficient - I believe
> this would circumvent any onclick event handlers set on the tag, which
> would prevent the AjaxLink from working...
>
> I'm thinking the hook for ajax links probably needs to be something like a
> combination of the two mechanisms - instead of trying to call click(),
> which doesn't exist, would need to call the onclick() directly, and then
> check it's result and if true follow the link, if false do not... that way
> it could still handle the ajax fallback links as well, I believe.
>
> This is all theory, haven't actually verified any of this would work
> yet...
>
> On top of all this, I'm working with a 1.4 backport we made of the
> input-events code, so any fix I come up with will likely not make it back
> into the main trunk for the input-events module...
>
> -Jason
>
>
> Nino Martinez-2 wrote:
>>
>> I cant exactly remember what the scope where, just that it did support
>> links at some point, in safari and IE. Patches are always welcome..
>>
>> But looking in the source there are some auto hooking for links
>> actually, which uses href instead of click AFAIR it should just pick it
>> up automaticly...:
>>
>>
>> function init${wicketComponentId}() {
>> shortcut.add("${keys}",function() {
>>
>>
>> window.location=document.getElementById('${wicketComponentId}').href;
>>
>> },{
>> 'disable_in_input':${disable_in_input},
>> 'type':'${type}',
>> 'propagate':${propagate},
>> 'target':${target}
>>
>> });
>> }
>> init${wicketComponentId}();
>>
>>
>> Did you check the examples, and see if they still are working, they do
>> include a link aswell?
>>
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples
>>
>
>
--
View this message in context:
http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21732636.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Issues with wicket-contrib-input-events in Mozilla
Nino,
Thanks for the quick reply...
I dug a bit deeper and you are correct, it does have some hooks for handling
Links, but it may only work for links which extend from the base Link class.
// Try to bind to link so shortcut will work. Should
only be done if
// no other handlers were found
if (component instanceof Link && eventType == null) {
linkUnbound = true;
return;
}
In my case, the link is an Ajax link which launches a Modal, and AjaxLink
does not extend Link. Furthermore, the behavior of simply handling the link
by calling location = href is not necessarily sufficient - I believe this
would circumvent any onclick event handlers set on the tag, which would
prevent the AjaxLink from working...
I'm thinking the hook for ajax links probably needs to be something like a
combination of the two mechanisms - instead of trying to call click(), which
doesn't exist, would need to call the onclick() directly, and then check
it's result and if true follow the link, if false do not... that way it
could still handle the ajax fallback links as well, I believe.
This is all theory, haven't actually verified any of this would work yet...
On top of all this, I'm working with a 1.4 backport we made of the
input-events code, so any fix I come up with will likely not make it back
into the main trunk for the input-events module...
-Jason
Nino Martinez-2 wrote:
>
> I cant exactly remember what the scope where, just that it did support
> links at some point, in safari and IE. Patches are always welcome..
>
> But looking in the source there are some auto hooking for links
> actually, which uses href instead of click AFAIR it should just pick it
> up automaticly...:
>
>
> function init${wicketComponentId}() {
> shortcut.add("${keys}",function() {
>
>
> window.location=document.getElementById('${wicketComponentId}').href;
>
> },{
> 'disable_in_input':${disable_in_input},
> 'type':'${type}',
> 'propagate':${propagate},
> 'target':${target}
>
> });
> }
> init${wicketComponentId}();
>
>
> Did you check the examples, and see if they still are working, they do
> include a link aswell?
>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples
>
--
View this message in context:
http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21730952.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Issues with wicket-contrib-input-events in Mozilla
Hi Duke dukejansen wrote: Additional testing with FireBug reveals that the JavaScript engine is reporting an error when the Escape or Enter key is hit: document.getElementById("cancelLink9d7").click is not a function http://.../resources/wicket.contrib.input.events.InputBehavior/shortcuts.js Line 4 It seems like somehow that click function doesn't exist in Firefox... Researching online a bit confirms this... for example: http://quomon.com/question_simulation-click-html-anchor-javascript_2786.aspx My guess is that the input-events package was written to work with buttons, which have a click event, and not anchor tags, which don't, which means I'll need to modify that code a bit to work with anchor tags... I cant exactly remember what the scope where, just that it did support links at some point, in safari and IE. Patches are always welcome.. But looking in the source there are some auto hooking for links actually, which uses href instead of click AFAIR it should just pick it up automaticly...: function init${wicketComponentId}() { shortcut.add("${keys}",function() {window.location=document.getElementById('${wicketComponentId}').href; },{'disable_in_input':${disable_in_input}, 'type':'${type}', 'propagate':${propagate}, 'target':${target}});} init${wicketComponentId}(); Did you check the examples, and see if they still are working, they do include a link aswell? https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples dukejansen wrote: Has anyone had any issues getting the wicket-contrib-input-events package to work properly with Mozilla? It seems to work great in IE, but somehow my events are not being picked up in Firefox. Specifically, let's say I have a link which launches a modal, and inside that modal is a panel with an OK button and a Cancel button. I have set up keyboard shortcuts so that Escape fires the Cancel onclick event and Enter fires the OK onclick event. This works great in IE, but in Firefox when I hit "Enter" it seems to think I'm clicking the link that was originally clicked to launch the modal - the link that presumably still has focus behind the modal mask. I believe that Nino actually tested against FF2, so I was surprised by this, and thought perhaps I'm seeing the result of some kind of interaction with other JavaScript on the page. Has anyone else run into this, and if so do you have any wisdom to share? Thanks. -Jason - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Issues with wicket-contrib-input-events in Mozilla
Additional testing with FireBug reveals that the JavaScript engine is
reporting an error when the Escape or Enter key is hit:
document.getElementById("cancelLink9d7").click is not a function
http://.../resources/wicket.contrib.input.events.InputBehavior/shortcuts.js
Line 4
It seems like somehow that click function doesn't exist in Firefox...
Researching online a bit confirms this... for example:
http://quomon.com/question_simulation-click-html-anchor-javascript_2786.aspx
My guess is that the input-events package was written to work with buttons,
which have a click event, and not anchor tags, which don't, which means I'll
need to modify that code a bit to work with anchor tags...
dukejansen wrote:
>
> Has anyone had any issues getting the wicket-contrib-input-events package
> to work properly with Mozilla?
>
> It seems to work great in IE, but somehow my events are not being picked
> up in Firefox.
>
> Specifically, let's say I have a link which launches a modal, and inside
> that modal is a panel with an OK button and a Cancel button. I have set up
> keyboard shortcuts so that Escape fires the Cancel onclick event and Enter
> fires the OK onclick event.
>
> This works great in IE, but in Firefox when I hit "Enter" it seems to
> think I'm clicking the link that was originally clicked to launch the
> modal - the link that presumably still has focus behind the modal mask.
>
> I believe that Nino actually tested against FF2, so I was surprised by
> this, and thought perhaps I'm seeing the result of some kind of
> interaction with other JavaScript on the page.
>
> Has anyone else run into this, and if so do you have any wisdom to share?
>
> Thanks.
>
> -Jason
>
--
View this message in context:
http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21718790.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Issues with wicket-contrib-input-events in Mozilla
Has anyone had any issues getting the wicket-contrib-input-events package to work properly with Mozilla? It seems to work great in IE, but somehow my events are not being picked up in Firefox. Specifically, let's say I have a link which launches a modal, and inside that modal is a panel with an OK button and a Cancel button. I have set up keyboard shortcuts so that Escape fires the Cancel onclick event and Enter fires the OK onclick event. This works great in IE, but in Firefox when I hit "Enter" it seems to think I'm clicking the link that was originally clicked to launch the modal - the link that presumably still has focus behind the modal mask. I believe that Nino actually tested against FF2, so I was surprised by this, and thought perhaps I'm seeing the result of some kind of interaction with other JavaScript on the page. Has anyone else run into this, and if so do you have any wisdom to share? Thanks. -Jason -- View this message in context: http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21718528.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
