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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] > >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 -~----------~----~----~----~------~----~------~--~---
