Wicket.Focus.attachFocusEvent is very slow in IE compared to FireFox.
At first I thought attaching an event was slow, but it seems to be just
iterating over the list of elements returned by
document.getElementsByTagName takes forever.
FF would take 17 ms, IE 900ms for a test page with 1200 links.
Another issue with attaching events to all of these elements is that it
occurs once in DOM load, but also after every ajax response. So my test
page with one ajax link, with an empty onClick(AjaxRequestTarget), there
is a 900ms delay after the response comes back even with no changes.
I changed the Wicket.Focus.attachFocusEvent function to do nothing, and
added these events (can be done before dom load)
Wicket.Event.add(window,'focus',Wicket.Focus.setFocus);
Wicket.Event.add(window,'blur',Wicket.Focus.blur);
So we capture all the focus and blur events inside the window, and call
the existing functions. The window gets the focus event for the element
first before it gets to the element and bubbles back up again. A quick
look at FF and IE show the same Focus/Blue events in the log, and the
delay is gone. The other benefit is you don't have to reattach events
after the ajax response changes the dom :)
Matej Knopp wrote:
Well, it kinda does. You can submit the links and buttons with
keyboard - and when you do it does make sense to preserve focus when
you replace the submitting button or link.
-Matej
On Fri, Apr 17, 2009 at 9:48 AM, Johan Compagner <[email protected]> wrote:
Buttons and links dont make much sense yes.
Dont remember why we should do this.
Will check the code
On 16/04/2009, 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]
--
Jason Lea
