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]
