Joel, I'm out of the office today, but I'll be sure to give it a shot first thing tomorrow and report back.
Thanks. - 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 -~----------~----~----~----~------~----~------~--~---
