Is there a way to know when a location.href redirect was triggered?

[Gernot Raudner]

i'm currently struggling a bit with different browser behaviour on location.href. chrome for example finishes executing the current stack and only then redirects, others redirect immediately (and sometimes even still execute the code).

so here's the code i'm testing:

window.onbeforeunload = () => console.log('1: beforeunload');
function redir(page) { setTimeout(() => console.log('5: deferred log'), 0); location.href = page; console.log('2: redirected!'); }
function doRedir() { redir('index.jsp?p=0'); console.log('3: further down the stack'); }
doRedir(); console.log('4: something');

results for firefox:

1: beforeunload debugger eval code:1:31

Navigated to http://localhost:8080/ajax/index.jsp?p=0

2: redirected! debugger eval code:2:99

3: further down the stack debugger eval code:3:46

4: something debugger eval code:4:12

undefined

5: deferred log

results for chrome:

2: redirected!
VM96090:3 3: further down the stack
VM96090:4 4: something
undefined
VM96090:1 1: beforeunload
VM96090:2 5: deferred log
Navigated to http://localhost:8080/ajax/index.jsp?p=0

so, imagine i don't know who or what triggered the redirect, or when it was triggered (no control over that code) - there's a lot that can happen between the call to location.href and the actual navigation in chrome, not so in firefox. imagine that my page is in some specific state when location.href is called, and i want to send back information about that state during onbeforeunload, this page state can change a lot in chrome during this "blackbox time".

can anyone think of a way how i could determine at which point i have to store the page state, so that i know what i have to send during beforeunload? i already tried it with proxies or getters/setters onto the location object but that simply doesn't work as it's not configurable. i even tried a few hacks (e.g. check location.href immediately after setting it - doesn't work since it's still the old value at this point in time).

[PhistucK]

I am not sure how you can determine that a new location has been assigned (or any other consistent stage for storing the state), sorry.

location.href should never show a different URL in your scenario. Only history.pushState or changing the hash can do something like this. 

 

The Firefox behavior seems a bit weird to me, it suggests (though it is probably not what really happens) that code from the previous page keeps executing after the navigation. I guess it is simply a queue that gets emptied once the navigation occurred (if you add performance.now() and new Date() to the logs and sort it by them when reading them, the order might be different. Enable time stamps in the console, if Firefox has that option).

Anyway - this might be an interoperability issue (in Firefox, beforeunload seems to fire synchronously while in Chrome, it does not).

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.