So, if I got you right, the benefit of using the workaround with the deferred command, is just, that the user is presented with the new page first: and then she has to wait for the 4.5 sec.
I'd rather disable the history tokens at all and present the users with a 'set current-URL' button or smth. like this. being stuck for 4.5(!!) sec (at whatever state of the app) is simply unacceptable. maybe you could implement some smart handling, so that the time for setting the history tokens are traced and when you notice that it takes >50ms on the clients browser, show him a warning dialog, explain why IE is shit and the disable history support - or redirect to a chrome/iron download page :) anyway: I would really be interested what takes IE so long to simply set the history token - the relevant code: http://tinyurl.com/d4zz6v seems ok. On Mar 20, 12:25 am, jay <[email protected]> wrote: > We experienced a very similar problem, though we're not using GXT. > Doing a navigation in IE was taking a crazy amount of time, whereas in > other browsers the navigation was fine. > > We wound up doing the navigations by getting the user > "gesture" (click, or whatever) indicating that they want to navigate. > When this happens, we do the work as if our history listener got an > event In addition, we manually track the history token. Then, in a > DeferredCommand, we do the History.newItem() call to update the > history stack. Of course, this means that we have to handle the case > that when our history listener gets a notification, but we're already > at that history token. It's not fun (and possibly bug-prone), but at > least our customers aren't cursing us... > > jay > > On Mar 13, 10:02 am, maku <[email protected]> wrote: > > > Hi, > > > we have a very strange performance problem especially in context with > > history handling and IE6 / IE7 > > > Our application is based on GXT and is already a rather large one (1.6 > > MB). > > > On less powerfull computers (e.g. Netbooks -> Asus EEE 1000h) the > > performance of history handling is really bad (calling > > History.newItem) > > > E.g. time performing History.newItem(...) lasts ca. 4.5 seconds > > > It seems that it depends on the size of the application. > > > When I try the same with a reduced app (size 980 KB) the performance > > is dramatically better (but of course not satisfying) -> Time to > > perform History.newItem(..) reduced from 4.5 seconds to 1.6 seconds. > > > Is it possible that the reason for this is IE's IFrame handling? > > > Does anybody of you know the reason for these kind of problems. Is > > there a solution to solve the problem (or to improve the situation)? > > > TIA > > > Martin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
