83

I've got a page that's redirecting when it shouldn't be, and I'm trying to figure out who's doing it. First I tried hijacking window.location:

window.location = (function (location) {
    // location is now hidden inside a closure. We can override it
    var Location = Object.create(location);
    // Location is now our proxy. We can use it to catch changes
    window.__defineGetter__('location', function () { return Location });
    window.__defineSetter__('location', function (x) { debugger; location = x; return x; });
    // etc etc, considered assignments to location.href, location.search, location.host etc., as well as calls to location.replace and location.assign
}(window.location));

That didn't work at all in Chrome. You can't do setters and getters on window.location for security reasons. OK. The next thing I tried was observing onunload and onbeforeunload:

['unload', 'beforeunload'].forEach(function (evName) {
    window.addEventListener(evName, function () {
        debugger; // Chance to check everything right before the redirect occurs
    });
});

I knew that the value of window.location would stay the same until after the onunload event, again for security reasons, but I was hoping for some other clue; no such luck. I next tried putting breakpoints at every point I can find in my own scripts where window.location could possibly be assigned. None of them are hit according to the Chrome debugger. Argh. This redirect is not happening in FF, by the way, and I already tried restarting Chrome. I feel like I've truly tried everything and gotten nowhere, which hopefully means I'm about to level up as a developer? Please?

Is there any way in any browser for me, the human operating the debugger, to break on the line that's redirecting the page location? I understand there are security implications for allowing automatic access to that information, but is there nothing that privileges the developer and allows a way to do it? If not, what's the normal way of dealing with a situation like this? It seems common enough and I don't think anyone likes getting blocked for hours or days on a conceptually simple problem. TIA

PC Jones
  • 875
  • 1
  • 6
  • 5
  • 2
    worst case you could just put a breakpoint somewhere and then manually step through the code until you find the offender – Andy Ray Jun 25 '12 at 18:25
  • 1
    True, and that's what I'm doing now, but as an exercise consider the case where the redirect comes from a dynamically included script tag: // Redirects to google.com document.body.appendChild(document.createElement('script')). appendChild(document.createTextNode(decodeURIComponent( '%77%69%6e%64%6f%77%2e%6c%6f%63%61%74%69%6f%6e%2e%61%73%73%69%67%6e%28%27%68\ %74%74%70%3a%2f%2f%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%27%29'))) This is why I'm wondering if there's a trick for cutting the gordian knot, or if not, what the pros do to minimize time spent on issues like this. – PC Jones Jun 25 '12 at 19:13
  • 2
    Any update on this? I'm trying the same thing. – Mike Atlas Jun 20 '14 at 02:32
  • 4
    https://stackoverflow.com/questions/12360187/break-javascript-before-an-inline-javascript-redirect-in-chrome is not really the same question, and has no answers for this question... – Jazz Apr 24 '18 at 12:38
  • 4
    yeah, one of the ridiculous things about stack overflow is people can come along and mark duplicates that aren't and there doesn't seem to be a way to unflag it. – PhysicalEd May 02 '18 at 16:29

1 Answers1

57

Network tab helps you, switch on preserve log checkbox, initiator column will contain the javascript location that caused the redirect.

Martijn
  • 1,440
  • 11
  • 18