Thanks Igor,
the suggested workaround seems to work fine. However, it is not enough
to just override the attachFocusEvent function -- you also need to
deregister the previously registered function. I did as follows (I
apologize for the lack of elegance, I'm not a js expert):
if (typeof(Wicket) != "undefined") {
if (typeof(Wicket.Focus) != "undefined") {
// Deregister old attachFocusEvent function
handlers = Wicket.Event.domReadyHandlers;
filteredHandlers = new Array();
for(i = 0; i < handlers.length; i++) {
if (handlers[i] != Wicket.Focus.attachFocusEvent) {
filteredHandlers.push(handlers[i]);
}
}
Wicket.Event.domReadyHandlers = filteredHandlers;
// Redefine and re-register attachFocusEvent
Wicket.Focus.attachFocusEvent=function() {
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
}
Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
}
}
By the way, I believe that this is, or has the potential of becoming,
a major stumbling block for others.
Should it be regarded as a bug?
kind regards, Peter
On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <[email protected]> wrote:
> you can try adding this to the head after wicket-ajax.js
>
> <script>
> if (Wicket!="undefined") {
> if (Wicket.Focus!="undefined") {
> Wicket.Focus.attachFocusEvent=function() {
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
> }
> }
> }
>
>
> -igor
>
> On Thu, Apr 16, 2009 at 9:16 AM, James Carman
> <[email protected]> wrote:
>> So, we understand what's slowing us down? Any way to turn that stuff
>> off on our end to get stuff working? I've got a release going out the
>> door that's slow as heck on IE right now.
>>
>> On Thu, Apr 16, 2009 at 12:03 PM, Igor Vaynberg <[email protected]>
>> wrote:
>>> this code is there so we can track focus and properly restore it after
>>> ajax modifies the dom. i am not sure why we need to track and restore
>>> focus on anchors, it is only important when you are typing so that the
>>> cursor doesnt move elsewhere - so only for textfields and textareas.
>>>
>>> johan, matej says you wanted to track focus for anchors, whats the deal?
>>>
>>> -igor
>>>
>>> 2009/4/16 Peter Gardfjäll <[email protected]>:
>>>> Hi James,
>>>>
>>>> I'm pretty sure that links are part of the problem.
>>>> To verify this, try replacing all <a> tags with e.g. <span> and see if
>>>> you can spot any difference in response time.
>>>> Alternatively, try replacing/commenting out ajax components/behaviors
>>>> on your page to prevent wicket-ajax.js from being pulled into the
>>>> page.
>>>>
>>>> cheers, Peter
>>>>
>>>> On Thu, Apr 16, 2009 at 3:52 PM, James Carman
>>>> <[email protected]> wrote:
>>>>> Peter,
>>>>> I have experienced similar problems just recently. I didn't narrow it
>>>>> down
>>>>> to the fact that the links were the problem, as you have, though! I have
>>>>> been racking my brains trying to figure this thing out. My page is
>>>>> similar,
>>>>> a table with lots of cells in them that are links. I've turned off CSS
>>>>> and
>>>>> other stuff trying to find the bottleneck. I didn't think for a moment
>>>>> that
>>>>> it might be the links.
>>>>>
>>>>> James
>>>>>
>>>>> 2009/4/16 Peter Gardfjäll <[email protected]>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am working on a wicket application intended to be executed both on
>>>>>> FF3 and IE7.
>>>>>> While working on this application I have discovered that the rendering
>>>>>> of some pages are a lot slower in IE.
>>>>>> The pages that were significantly slower on IE have a couple of things
>>>>>> in common: they are ajax-enabled and have lots of links.
>>>>>> These pages all appear to freeze for a while after all data has been
>>>>>> transferred, but before the page becomes responsive.
>>>>>>
>>>>>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>>>>>> which gets pulled in whenever an Ajax component/behavior is added to a
>>>>>> page, registers a function
>>>>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>>>>>> {input,select,a,textarea,button} tags in the DOM tree when the page
>>>>>> has been loaded.
>>>>>>
>>>>>> I timed this function for one of my pages (containing a single big
>>>>>> table with around 300 rows, with each row having about six links).
>>>>>> When the function is registered, the fireDomReadyHandlers in
>>>>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>>>>>> registered. In firefox, the corresponding numbers are about 470 ms and
>>>>>> 400 ms.
>>>>>>
>>>>>> Hence, there seems to be quite a performance penalty involved in
>>>>>> loading ajax pages with lots of links in IE7.
>>>>>> I'm a bit worried about this overhead, particularly since I have a
>>>>>> rather fast machine (a lot better than most of the end users anyway).
>>>>>> I would not be surprised if clients see double page load times.
>>>>>>
>>>>>> Have anyone on this list experienced similar problems?
>>>>>> Is this a known issue? (I have not been able to find anything similar
>>>>>> on the mailing list)
>>>>>> Any suggestions or pointers are welcome.
>>>>>>
>>>>>> best regards, Peter
>>>>>>
>>>>>> /PS By the way, I am using wicket 1.3.5.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
