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]

Reply via email to