Develop Reference

How can I debug "Back Navigation Caching" in IE?

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.
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: The code on this page disabled back and forward caching. For more information, see: 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
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.
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.
Short of putting the whole browser into a Windows debugger, you can pretty much forget about setting breakpoints. All you can do is log.
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.
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).
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.

window.open affect web page

I have a link that opens a new window using window.open. The pop up works fine, however the normal web page stops loading objects (images, scripts, ajax scripts) and sometimes the page doesn't load at all.
Here is my code:
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
Is there anything I am doing wrong?
Thanks,
Peter

First of all, please be more specific: tell us more about your browser and which version, and possible your OS. It could be more related to the browser than to the web content.
Then on to the possible problem; you start with saying "I have a link that ...".
To me that sound like you use <a href="javascript:DoSomething()">. Or perhaps <a href="#" onclick="DoSomething()">.
I tried both in some modern browsers: Chrome v37, IE v11. Both browsers did not produce what you describe:
- Chrome v37 will happily keep on loading, even if I immediately click a "window.open()"-link on top of a (huge) webpage;
- IE v11 will someshow show "false", which is strange, but still not what you got.
In some cases I also got to deal with the popup blocker.
A general tip might be to NOT USE <a href> for things like this. Behaviour seems inconsistent across browsers, also these days there are better alternatives, such as <span onclick="">...</span> and <button onclick="">...<button> or by using JQuery or other frameworks (which I do not know much about).
Although this many not be a conclusive answer, maybe this can help you experiment on your own, and think about possible causes or alternative ways of doing things.

The behaviour you describe should definitely NOT normally happen. This is confirmed by robbmj's JSFiddle, that fails to reproduce the problem. That's evidence that something is going on in the main page that is not plain vanilla page loading, or your "link opening" has something unusual to it. Apart from the syntax error (you use four parameters, not three).
Since you do not supply information on either of these points (how do you load the main page? How do you trigger the popup-opening code?), we do not even know if the problem
might be browser-related; I'd start and try to test things in IE, Chrome and Mozilla to see
whether anything changes; this might provide some useful insights.
One possibility
A very strong possibility is that your inadvertent fourth parameter goes into the window.open() "replace" parameter, which is a boolean, and triggers undefined behaviour or simply an error that stops everything. You should have things somewhat working in IE and not working at all in Firefox.
You should also be able to see whether this is the case by using Firefox and the Firebug extension, or the Web Developer Console in Chrome.
Another possibility
A more esoteric possibility is that the way you define the link might make the browser believe you've actually moved on to another page, so that there's no point in continuing loading the current page. Depending on the browser, this might have to do with how the link is defined and could be remedied by defining it some other way.
For example it could conceivably happen if you had
...
which I suspect is what led user Tomzan to ask, "is the link something like javascript:...?"
So if this is the case, try with this instead (this works for me in IE9/Chrome/FF):
link
function openPopup() {
MyWindow = window.open('player.php', 'Player', 'width=500, height=300');
// Also try the following. You won't probably like the results (it should send the
// popup window behind), but if it works, it proves we're dealing with a browser
// issue there.
// Blur and refocus
// MyWindow.blur();
// window.focus();
// Just focus
// window.focus();
return false;
}
Workaround
A possibly acceptable workaround could be to disable the link altogether (or hide it via CSS), and only reactivate/show it upon main document being ready. This sidesteps the problem, even if user experience could be somewhat worse due to a longer wait.
But if it's so likely that a user clicks on the link before waiting for the whole page to load, I'd also consider not automatically loading the rest of the page at all, and reorganize information to provide a more streamlined navigation. Or maybe distribute it on two sequential pages. Again, unfortunately you did not supply enough information to do more than guess.

As you probably know, JavaScript is single threaded. Every event is queued until there is idle time for it to be executed.
In the case of window.open, both windows must share a single context to keep it thread-safe because the opened window can access to it's parent using window.opener.
I don't know how browsers implements it, but we can guess two possibilities:
Idle time is shared between the two windows. It means if the popup does many blocking statements, it can freeze the main window's events.
Only one of the two windows can be active, which depends on which one has the focus. In that case, all events may be paused in the main window when you're using the popup.
If you want a more precise answer, I need more details about your code.

document.addEventListener("DOMContentLoaded", function () {
//whatever the code
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
}, false);

Try to wrap the code in SetTimeout
setTimeout(function () {
window.open( .. )
}, 0);

Your document should be loaded first, then popup should be open, So write your javascript code in the scope of $(document).ready().
enter code here
$(document).ready(function(){
$("#clickme").click(function(e){
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
});
});

Debug webpage redirects in browser

I am debugging a web application which redirects several times on page load. Page A redirects to page B, which redirects to page C. I don't know what methodology is used (e.g. JavaScript, HTTP redirects, etc.).
What I'm looking for is a debugger to break before a page gets redirected, so that I can inspect exactly what method is being used to redirect, and what data is being sent to next page in the redirect chain.
Is there a simple way to do that? I'm debugging on Windows, so Chrome, Firefox and IE are all available.
UPDATE: It seems that Fiddler is the best option available. I marked the answer from #cgatian as a solution, since his was the Fiddler idea.

In Chrome there is Event Listener Breakpoints -> Sript -> Script First Statement:
Pressing F8 will stop on first statement of any script in page, e.g :
<script type="text/javascript">document.location.href='http://www.example.com'</script>
Also, there is Event Listener Breakpoints -> Load -> beforeUnload but not works in my case.

Alright so it sounds that you want to actually look at variables inside the browser before the redirect occurs. One way I can think of (without modifying the source directly) is to use Google Chrome Snippets.
You could create you're own snippet that binds to the onbeforeunload event.
Step By Step Instructions on Creating a Snippet
Snippet code:
window.onbeforeunload = function(){
var debug;
return;
}
All I am doing in the above code is attaching an event before the browser would be redirected.
If you then place a break point inside your snippet you will be able to break and inspect the variables on the page. (Don't forget to right click your snippet and select Run) before debugging.

In chrome, in the debug window, at the very bottom, are a series of buttons. Click the button that is a dark black circle. It will preserve the log upon navigation. I think that is what you want.

How to debug a whole web page with firebug

suppose i am seeing the site http://www.webspiders.com/ and i want set break point and debug the whole page. whenever i click or mouse over any element and for this action if any javascript is fired then i need to see and debug that javascript too. please help me with detail instruction for debugging with firebug. thanks.

You can enable the "Break On Next" button near the top left of the "Script" tab of Firebug. Once enabled, Firebug will break as soon as JavaScript is executed.

You will need to know where to place your breakpoints or must place a breakpoint ta all reachable members of every js file. A help would be the framework that the site use, if the is any.

Here's a tutorial on setting breakpoints in Firebug.

On the firebug script tab:
1. click on the number where you want to break the script
2. refresh

Use Javascript to open/activate Firebug

I've been looking for a solution to use Javascript to open or activate Firebug.
You see by default, Firebug is deactivated/closed at the corner of the status bar.
You need to click the icon to activate Firebug (the icon becomes coloured).
Is there a way to activate Firebug via Javascript in the javascript code?
see following:
// check if firebug is installed and activated
if(window.console && window.console.firebug){
// do firebug debugging and so on
}else{
alert('Firebug is not installed or activated.');
}

If you are trying to troubleshoot your own code, you can use the javascript "debugger" command to cause firebug to break on a given line of code. You will have to enable firebug debugging first for that web page. Maybe that's more along the lines of what you were looking for?
I don't think you want to trigger Firebug to open on an end user's browser; this would, at best, cause confusion for the average user.

Well, if Firebug is deactivated then its not active and cannot respond to anything. You have to actually turn it on before it can accept calls from a web page.

If there is, that option could possibly be a security hazard. Basically, you're telling FF to start up the debugger. If you could tell this debugger to even do a few things more then it could be misused by hackers.