Opened issue 3808 and attached a patch to it that reverts the change and fixes the issue for me. It's interesting you mentioned IE6/7. I didn't test them as thoroughly as IE8, but I did notice a HUGE added delay in newToken calls at one point, in the range of 10-20 seconds. I'm not sure if this was directly related to the XHR change or any of the number of hacks I was trying out at the time though.
Thanks. - Amir On Tue, Jul 7, 2009 at 5:45 AM, Joel Webber <j...@google.com> wrote: > Changing IFrameTemplate to do a location.replace on the iframe probably > made a difference because it loaded the compiled script normally, rather > than through xhr/doc.write. But there are other problems with this -- though > it shouldn't fetch the compiled script twice, it effectively loads it twice, > once via xhr and once via location.replace. > I'm starting to suspect that this xhr/doc.write trickery is implicated in a > few strange issues. I originally put it into place to guarantee that the > compiled script be fetched asynchronously alongside any other resources in > the outer page (which it does). > > But it appears to be causing at least this problem, and I suspect it's also > making the compiled script difficult to debug in Firebug, as well as (maybe) > causing history navigation to become surprisingly slow on IE6/7. Would you > mind creating an issue for this particular case so that I can track it? I'm > going to try reverting this change locally to see which, if any, of these > issues are resolved. > > Thanks, > joel. > > > On Wed, Jul 1, 2009 at 10:57 PM, Amir Kashani <amirkash...@gmail.com>wrote: > >> >> I've verified that making the following changes to the 1.6 release >> branch causes the bug: >> >> - Replace IFrameTemplate.js with tr...@r5523 >> - Modify line 430 to not append .cache.html (seems to be appended >> from somewhere else in the 1.6 branch) >> - Replace hosted.html with tr...@5517 (not really necessary, as I'm >> testing with compiled code) >> >> Now, set your face to stunned. I modified IFrameTemplate.js to skip >> the XHR request and instead do a location.replace on the frame in >> maybeCreateGwtFrame(). This single change fixed the issue. Again, I >> can't begin to explain why populating the frame using document.write >> versus setting the location would cause IE to lose history state. >> >> I'm going to continue to work to try and find a simple example to >> replicate this, though thus far I haven't had any luck outside of my >> app. >> >> - Amir >> >> On Jul 1, 3:01 pm, Amir Kashani <amirkash...@gmail.com> wrote: >> > Joel, >> > >> > The 1.6 release branch does not exhibit the problem; it works fine. >> > The next thing I'll try is copying the IFrame linker changes over to >> > the 1.6 branch and see if that's enough to cause the problem. Unless >> > you have another suggestion? >> > >> > - Amir >> > >> > On Jun 30, 5:32 am, Joel Webber <j...@google.com> wrote: >> > >> > >> > >> > > Amir, >> > > I'd be very interested in any way you can find to reproduce this bug >> > > reliably. The History implementation in IE8 is very simple, because >> they >> > > added direct support for using the url #hash to update the history >> state, >> > > and for the onhashchange event. It is possible that we're doing >> something in >> > > the iframe linker's bootstrap script to tickle this bug, though it's >> not >> > > clear to me what that might be. >> > >> > > Since you're building with trunk right now, you could also try >> building >> > > against the current contents of the 1.6 release branch >> (/releases/1.6), >> > > which has full IE8 support, but not the linker changes. We're going to >> be >> > > releasing out of this branch very soon (as soon as we merge the fix >> for a >> > > Firefox 3.5 regression they are shipping today). >> > >> > > Cheers, >> > > joel. >> > >> > > On Tue, Jun 30, 2009 at 12:01 AM, Amir Kashani <amirkash...@gmail.com >> >wrote: >> > >> > > > I’m having a strange issue with trunk and IE8 where the browser’s >> > > > history stack inexplicably “disappears”. That is, the history drop >> > > > down list empties (including previously visited non-GWT sites, like >> > > > MSN) and the back/forward buttons don’t work. My guess is that this >> is >> > > > a bug in IE8 that GWT is somehow triggering since as far as I know, >> an >> > > > application can’t explicitly clear a browser’s back history. >> > >> > > > I haven’t been able to find a definitive set of steps to duplicate >> > > > this. I’ll be clicking along, adding items to the history stack and >> > > > regularly checking the history drop-down menu until at some point, >> the >> > > > list is either completely empty or only contains the current page. >> > > > Other times, I’ll click back or forward, and as soon as I do, the >> > > > buttons become disabled (list is empty). To complicate matters, I >> > > > haven’t been able to create a simple example that exhibits the bug; >> it >> > > > only occurs with my fairly large application. >> > >> > > > I _think_ I’ve narrowed down the issue to a change made to the >> IFrame >> > > > linker in r5393. Using r5392, history works exactly as expected. >> > > > Unfortunately, I can’t use r5393 directly, as it has a bug which >> isn’t >> > > > fixed way until r5523, where document.body is accessed before it is >> > > > initialized, causing my app to not load at all. Swapping out >> > > > IFrameTemplate.js with r5523’s version exhibits the broken behavior >> > > > with r5393. >> > >> > > > I can’t for the life of me explain how the IFrame linker change >> causes >> > > > this, or why it’s not a consistent set of steps (timing issue?) or >> why >> > > > it only happens with my application and not smaller ones. >> > >> > > > Any insight or tips on how to further track down the problem so I >> can >> > > > submit a coherent bug report would be greatly appreciated. >> > >> > > > - Amir >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
