我该如何调试“后退导航缓存"?在IE中? [英] How can I debug "Back Navigation Caching" in IE?

问题描述

我看到了IE中一个奇怪的错误，而我却没有在Chrome中看到这个错误.具体来说，这涉及到在(Telerik)向导导航回其第一步时未触发某些JS代码.

I'm seeing an odd bug in IE that I'm not seeing in Chrome. Specifically, this involves some JS code not firing when a (Telerik) wizard is navigated back to it's first step.

当用户单击其上一个"按钮时，某些数据未正确加载.击中F12并调出开发人员控制台已向我显示以下警告:

When the user clicks their "Previous" button, some data isn't being properly loaded. Hitting F12 and bringing up the developer console has shown me the following Warning:

DOM7011:此页面上的代码禁用了反向缓存和正向缓存.有关更多信息，请参见: http://go.microsoft.com/fwlink/?LinkID=291337

好吧，所以我转到提供的链接，我注意到文档状态:

Ok, so I go to the link provided and I noticed the documentation states:

In order to be cached, webpages must meet these conditions:
...
 - The F12 Developer tools window isn't open

这是一个问题，因为当我打开向导窗口时使用向导中的导航按钮时，它的行为就像在Chrome中一样.

This is a problem, because when I use the navigation buttons within my wizard WHILE the dev window is open, it behaves properly, just as it does in Chrome.

如何调试相关的Javascript，以便弄清发生了什么事?另外，我了解什么是缓存，但是我不确定这是什么意思，也不知道Chrome为何会有不同的表现.有没有一种方法可以强制IE像chrome一样运行，并关闭(或关闭)导致此问题的所有功能?

How can I debug my related Javascript so I can figure out what's going on? Also, I understand what caching is but I'm not exactly sure what this is about and I have no idea why Chrome behaves differently. Is there a way that I can force IE to behave like chrome and cut on (or off) whatever features that are causing this issue?

推荐答案

糟糕.回到您的旧学校调试中.

Yuck. Back to old school debugging for you.

将整个浏览器放入Windows调试器的时间很短，您几乎会忘记设置断点.您所能做的就是记录.

Short of putting the whole browser into a Windows debugger, you can pretty much forget about setting breakpoints. All you can do is log.

如果幸运的话，您的问题还不是很深，则可以使用一些简单的alert()语句让您知道代码各个阶段的状态.一件好事是，您现在可以很好地序列化对象了.例如，您可以执行JSON.stringify(this)，这可能会为您提供巨大的输出，您可以将其复制并粘贴到IDE中并解压缩.这样做的主要好处是警报将被阻止，因此您可以花些时间研究输出.这样做的主要缺点是现在种族状况的可能性要大得多.

If you are lucky and your problem isn't too deep, you can use a sprinkling of simple alert() statements to let you know the state of things at various stages in your code. One nice thing is that you can serialize objects now pretty nicely; for example, you can do JSON.stringify(this), which will probably give you a giant output, which you can copy and paste into your IDE and unpack. A major upside to doing this is that the alert will block, so you can take your time studying the output. A major downside to this is that race conditions are now much more likely.

或者，您可以在页面上添加<textarea>并将您的JSON.stringify(this)结果放入页面中.因为这意味着额外的DOM突变，所以它也增加了竞争条件的几率，但幅度并不大. (如果有可能出现竞赛条件，则可以执行以下操作:

Alternatively, you can add a <textarea> to the page and throw your JSON.stringify(this) results into that. Because this means extra DOM mutations, it also increases the odds of race conditions, but not by much. (If race conditions are a possibility, you can do this:

(function () {
    var currentState = JSON.stringify(this);
    setTimeout(function () {
        document.querySelector('textarea').value = currentState;
    }, 1000);
})()

即使它们现在是异步的，但如果您依次使用多次，它们将以相同的顺序执行(除非您更改超时时间).

Even though these are now asynchronous, if you use this multiple times in sequence, these will execute in that same sequence (unless you change the timeout period).

如果您正在执行实际的页面导航(而不仅仅是使用pushState()更改URL)，那么实际读取这些日志将是一个问题.解决方案是将页面放在一个框架中，然后将内容写到同级框架中.只要两个框架都在同一个域上运行，就可以将数据推送到同一个框架中.如果您不能将它们放在同一个域中，那么您就很困惑.

If you are doing actual page navigations (and not just changing the URL with pushState()), then actually reading those logs is going to be a problem. The solution is to put the page in a frame and write the content out to a sibling frame. As long as both frames are running on the same domain, you will have no problem pushing the data into the sibling frame. If you can't put them on the same domain, you are kind of screwed.

这篇关于我该如何调试“后退导航缓存"?在IE中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！