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