[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 amirkash...@gmail.com 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 amirkash...@gmail.com 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 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
[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 j...@google.com 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 amirkash...@gmail.comwrote: 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 amirkash...@gmail.com 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 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
[gwt-contrib] Re: IE8 disappearing history
On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani amirkash...@gmail.com 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 j...@google.com wrote: On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani amirkash...@gmail.comwrote: 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 j...@google.com 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 j...@google.com wrote: On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani amirkash...@gmail.comwrote: 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 j...@google.com 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 j...@google.com 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 j...@google.com wrote: On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani amirkash...@gmail.comwrote: 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
Oh, poop. That's both entirely logical and completely insane. - James On Tue, Jul 7, 2009 at 4:11 PM, Joel Webber j...@google.com 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 j...@google.com 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 j...@google.com wrote: On Tue, Jul 7, 2009 at 1:40 PM, Amir Kashani amirkash...@gmail.comwrote: 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
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.comwrote: 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 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.comwrote: 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 -~--~~~~--~~--~--~---
