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
-~----------~----~----~----~------~----~------~--~---

Reply via email to