Okay, since this code does show that the problem is with the focus stuff and we have conflicting goals here, what are we going to do to move forward? Obviously, the IE JS engine is way too darn slow to handle this code. Is there some optimization we can do here? Should we file a JIRA? Is there one change in particular that made this so slow in IE? Do we back that out until a better alternative is known? Why am I asking so many questions? :) Sorry, too much coffee this morning.
2009/4/17 Peter Gardfjäll <[email protected]>: > Sure, > here goes. I have added both the java and the js file to the same Java > package: > > WicketAjaxJsPatch.java > ================== > > /** > * {...@link IBehavior} that should be added to {...@link Page}s that need to > prevent > * the page load performance penalty incurred when wicket-ajax.js traverses > all > * <a> tags in the page markup. > * > * <p/> > * For background information, see <a > href="http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html"; > * >this mailing list thread</a> > * <p/> > * This behavior simply makes sure that our patch gets applied to > wicket-ajax.js > * (by forcing wicket-ajax.js to be added to the page head prior to > * wicket-ajax-patch.js). > * > */ > public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior { > > �...@override > public void renderHead(IHeaderResponse response) { > super.renderHead(response); > response.renderJavascriptReference(new ResourceReference( > WicketAjaxJsPatch.class, "wicket-ajax-patch.js")); > } > > �...@override > protected void respond(AjaxRequestTarget target) { > // Does nothing. The fact that we are extending > // AbstractDefaultAjaxBehavior means that we will pull in > // wicket-event.js and wicket-ajax.js. The job of this behavior is to > // make sure that our wicket-ajax-patch.js script gets added to the > page > // head after those scripts. > } > } > > > wicket-ajax-patch.js > =============== > > /** > * Overrides the attachFocusEvent function registered by wicket-ajax.js. > * The original version traverses all anchor and button tags on the page > * which incurs a major performance penalty on pages with many links. > * This version skips these elements in the scanning. > */ > 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); > } > } > > > Attaching the behavior > ================= > What I do then is to add the WicketAjaxJsPatch to the page by doing. > > page.add(new WicketAjaxJsPatch()); > > > It seems to be doing its job for me. Please tell me if it doesn't work. > > cheers, Peter > > > On Fri, Apr 17, 2009 at 12:15 PM, James Carman > <[email protected]> wrote: >> Did that code actually work for you? I tried adding this js, but i >> couldn't get it to show up in the correct place. And, when I did, it >> didn't seem to improve much. Care to share your code? >> >> 2009/4/17 Peter Gardfjäll <[email protected]>: >>> I have written a simple WicketAjaxJsPatch Behavior which simply adds >>> the aforementioned javascript to the page. >>> In our application, we have several pages that suffer from the same problem. >>> It would be tedious to have to update all of these pages one-by-one. >>> So is there any way for me to add this Behavior to my parent page >>> (which other pages extend) and still have the javascript rendered last >>> in the head? >>> >>> regards, Peter >>> >>> 2009/4/17 Peter Gardfjäll <[email protected]>: >>>> 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] >>> >>> >> >> --------------------------------------------------------------------- >> 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]
