[gwt-contrib] Re: IE8 "disappearing history"
Oh, poop. That's both entirely logical and completely insane. - James On Tue, Jul 7, 2009 at 4:11 PM, Joel Webber wrote: > FWIW, I also dug into it in windbg, and it appears that the compiled script > was getting serialized as part of IE's "fast-back" functionality, probably > as a consequence of the fact that the script elements were created via > doc.write rather than being fetched through the browser's normal mechanism. > > > On Tue, Jul 7, 2009 at 4:09 PM, Joel Webber wrote: > >> Yup, the XHR-based IFrameTemplate seems to have been causing the HUGE >> delay you and I were both seeing when setting the url #hash for >> History.newItem(). I'm afraid I'm going to have to revert back to the >> more-poorly-parallelized version of the selection script to get this fixed >> (at least for now). Thank god we didn't put this in the 1.6 release branch. >> >> >> On Tue, Jul 7, 2009 at 2:29 PM, Joel Webber wrote: >> >>> On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani wrote: >>> 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. >>> >>> I'm glad to hear you say that, as I'm about to run a test on my end to >>> see whether the XHR change is causing that issue. I'll keep everyone posted. >>> >>> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
I have mixed emotions about this: glad I was right in my conclusion but the loss of parallelization is a bummer. For a while there, I assumed you wrote me off as an insane man ;-) Thanks. - Amir On Tue, Jul 7, 2009 at 1:11 PM, Joel Webber wrote: > FWIW, I also dug into it in windbg, and it appears that the compiled script > was getting serialized as part of IE's "fast-back" functionality, probably > as a consequence of the fact that the script elements were created via > doc.write rather than being fetched through the browser's normal mechanism. > > > On Tue, Jul 7, 2009 at 4:09 PM, Joel Webber wrote: > >> Yup, the XHR-based IFrameTemplate seems to have been causing the HUGE >> delay you and I were both seeing when setting the url #hash for >> History.newItem(). I'm afraid I'm going to have to revert back to the >> more-poorly-parallelized version of the selection script to get this fixed >> (at least for now). Thank god we didn't put this in the 1.6 release branch. >> >> >> On Tue, Jul 7, 2009 at 2:29 PM, Joel Webber wrote: >> >>> On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani wrote: >>> 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. >>> >>> I'm glad to hear you say that, as I'm about to run a test on my end to >>> see whether the XHR change is causing that issue. I'll keep everyone posted. >>> >>> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
FWIW, I also dug into it in windbg, and it appears that the compiled script was getting serialized as part of IE's "fast-back" functionality, probably as a consequence of the fact that the script elements were created via doc.write rather than being fetched through the browser's normal mechanism. On Tue, Jul 7, 2009 at 4:09 PM, Joel Webber wrote: > Yup, the XHR-based IFrameTemplate seems to have been causing the HUGE delay > you and I were both seeing when setting the url #hash for History.newItem(). > I'm afraid I'm going to have to revert back to the more-poorly-parallelized > version of the selection script to get this fixed (at least for now). Thank > god we didn't put this in the 1.6 release branch. > > > On Tue, Jul 7, 2009 at 2:29 PM, Joel Webber wrote: > >> On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani wrote: >> >>> 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. >>> >> >> I'm glad to hear you say that, as I'm about to run a test on my end to see >> whether the XHR change is causing that issue. I'll keep everyone posted. >> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
Yup, the XHR-based IFrameTemplate seems to have been causing the HUGE delay you and I were both seeing when setting the url #hash for History.newItem(). I'm afraid I'm going to have to revert back to the more-poorly-parallelized version of the selection script to get this fixed (at least for now). Thank god we didn't put this in the 1.6 release branch. On Tue, Jul 7, 2009 at 2:29 PM, Joel Webber wrote: > On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani wrote: > >> 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. >> > > I'm glad to hear you say that, as I'm about to run a test on my end to see > whether the XHR change is causing that issue. I'll keep everyone posted. > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani wrote: > 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. > I'm glad to hear you say that, as I'm about to run a test on my end to see whether the XHR change is causing that issue. I'll keep everyone posted. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
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 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 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 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 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 > >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 >> > > > l
[gwt-contrib] Re: IE8 "disappearing history"
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 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 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 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 >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 sma
[gwt-contrib] Re: IE8 "disappearing history"
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 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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: IE8 "disappearing history"
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 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 -~--~~~~--~~--~--~---
