We Keep Coding

Prevent the URL from changing when popstate occurs

Hi I'm trying to implement a "Are you sure you want to leave this page?" popup when navigating away from a page with a modified form that hasn't been submitted. The website is a single page app built using a custom framework.
Since all anchor links are handled by the framework it can tell that clicking a side nav link will cause a page change and show a Bootstrap confirm dialog. If the user clicks "Ok" the click goes through and an AJAX call is made to pull the new page content. If they click "Cancel" the modal is dismissed and they stay on the current page.
The part I haven't been able to solve is when a user clicks the "Back" button in their web browser. This triggers the "popstate" event. All navigation/history is managed using the history API since it's a single page app.
The issue is that when someone clicks "Back", the URL changes since "popstate" occurred, then I show my "Are you sure you want to leave?" modal. When the event occurs the URL in your address bar now shows the page you would go to from your history, not the page you're currently viewing. If you click "Cancel" in the Bootstrap confirm you are now left with the wrong URL displayed in your address bar.
event.preventDefault, event.stopPropagation, or return false inside popstate don't stop the URL from changing. AFAIK you can't intercept the "Back" button before "popstate". Trying to window.history.replaceState inside "popstate" doesn't seem to work either.
Does anyone have a solution on how to make this work?
Can you stop the URL from changing in the "popstate" event?
Can you rewrite the history somehow in "popstate" to change the URL back to what it was on the current page and retain the previous entry if you do decide you want it to go through after a modal has been accepted?
Some other solution I haven't thought of?
My original thought was to block the URL change in "popstate" then let the framework trigger the link click to load the new content and change the URL if they click "Yes" but I haven't found a way to do that.
Thanks!

I solved this by doing the following;
Each time a history state is created I generate a timestamp as a guid
The current timestamp is stored in a variable on the top level module
When popstate occurs the incoming history state's guid is compared against the top level modules guid
If the new guid is greater we're going forward, if it's less we're going backward
When the user clicks the back/forward button the hash does change to the incomming URL. If the user clicks cancel it runs history.go( direction ) where direction is 1 or -1 depending on the timestamps. This sets the URL back to what it should be and doesn't do anything weird to the history stack. The top level history variable has a flag to know that we're faking a page change so the link load logic in popstate is not executed.
The only quirk is if the user does click yes to navigate away when that request is sent and returned and a history object is created you do not update the top level module's guid. If you do the guid comparison will always think you're going backward because the new event you just added will always be the highest number. This may not be an issue if you don't make new requests for history URL's but our framework does so it doesn't display stale data like the browser typically does.
It's not ideal since you do see the URL change (no content changes) but so far it seems to work well enough. Another solution I found was to store your own site's history in local/session storage and compare URLs instead of using guid timestamps to find the popstate direction. This won't work in Safari's private browsing mode since both storage layers are disabled so I opted for guid's.

Detect 'Allow app to launch' Window JavaScript

I am developing a SharePoint App that basically launches a form in a Windows 8 application once the action is clicked. This is working perfectly fine. However, once you select this action, you are redirected to a page that basically holds some parameters to launch the app. This page throws a window that asks the user if it's okay to launch the app:
How can I detect if this has been launched or not? Ultimately I'd like to detect if the user hits 'Allow' or 'Cancel' but either scenario will work. I am trying to redirect a user to the parent page once this window has launched (hopefully when the user clicks 'Allow'
Is this possible? I found a helpful thread here: http://support.smartbear.com/viewarticle/55730/
However, this thread is very useful but doesn't give me the answer I need. I've tried using jQuerys .blur and this works(ish). It isn't giving me a consistent response but looks like it's a step in the right direction (if I can't detect the window that launches). I've also tried the following code by using .hover but am receiving inconsistent results.
$(window).hover(function (event) {
if (event.fromElement) {
console.log("inactive");
window.location.href = "http://google.com";
}
else {
console.log("active");
}
});
At the highest level possible, I'm trying to redirect the user once the app is launched.
Thanks in advance for any helpful input.

Why Internet Explorer differs from the expected functionality on a back button

In my ASP.NET MVC project, we have introduced Lucine Searching, (Though in this context these details are not required, just giving some background, because I believe my issue has something to do with IE browser and caching).
In this page the user can filter their search based on a keyword. And the user can click to go to the listed out items and come back to the same page with the browser back button or a manual HTML button which has the javascript code, onclick = "location.href = 'Javascript:history.go(-1);'" ).
In Chrome, Firefox and even in Internet explorer 9, user gets back the page where he left off without any issues. I meant it keeps the value the user entered.
However both in IE 10 and IE 11 when the user clicks on the filtered list item it goes into the page and when user clicks either on the browser back button or HTML back button first time I get back the correct filtered page. However when the user again clicks on any of the item, and do the same procedure, I will not get back the filtered value. Instead with all the results, even the text box will not have the keyword entered by the user.
It is always assumes that the back button is there to help the people get back the same page and state where they left. I left with out any clue why IE 10 and 11 acts differently. Could any of you please help me to figure out what I am missing here.

In special cases (where just the url of the page can not determine state - because of some internal in-page dynamic functionality), We need to implement the history handling for ourselves.
Setting History tokens – Whenever the user takes an action that changes the
“screen” in a way that you want to save, you should store
a token
History.newItem("someLinkTarget", false);
Responding to History tokens
Whenever the URL ends in #someToken, that token is passed to the onValueChange method of the History’s ValueChangeHandler
public void onValueChange (ValueChangeEvent<String> event) {
String linkTarget = event.getValue();
if (checkForYourSavedToken(linkTarget)) {
... your code displays your expected results;
} else { … }
This knowledge is from GWT reading though, I did not test this at its core. Please ignore if this does not help you anyway. (Also please find w3schools which suggests that There is no public standard that applies to the history object, but all major browsers support it.

If you're using ajax within the page, then leaving & coming back, that ajax state will be lost. A page does not persist any changes made after it's loaded when you click forward or back.
That's not strictly true though. Forms are persisted and I've used this trick in the past.
Page loads & user does a search which is loaded via ajax. Save the ajax response to a hidden input.
When the user leaves the page & returns, the page script detects there is now content in the hidden input & processes this, displaying the previously retrieved results to the user.

Cancelling in beforeunload event handler leaves browser URL changed

I am using the beforeunload event to get users to confirm that they want to leave my web page (and lose their input). It works fine except for one case: if they try to navigate away by typing a new URL into the address bar, and then cancel, they remain on my page but the address bar still shows their new destination.
This is harmless but annoying, so I am looking for a way to set the address bar back to my URL, without causing a refresh.
This is my code:
<script type="text/javascript">jQuery(window).bind('beforeunload', function () {
return 'This will end your session.';
});
</script>

You can't programatically change the content of the address bar unless you actually send the user to a new page. If you could, phishing would be much, much easier. "Hmm, the browser says I'm at https://safebankingsite.com, I guess it's OK to enter my SSN."

I even tried adding an anchor to the page:
Change Location
Clicking that does not even fix a deleted address. I would think this verifies you can't do it.

Using Javascript in Firefox add-on to get what is currently typed into the url bar

I'm writing a Firefox add-on and trying to get what is currently typed into the address bar, but every time I try, I get a null error. The code I'm using is
var url = document.getElementById("urlbar").value;
However, when I do that, the error I get is
Error on line 1: document.getElementById("urlbar") is null`.
I have a blank tab open with text written into the address bar. This is in firefox 3.6.9 .
Any help would be appreciated. Thanks!
Edit: If there is no way to get the contents of the URL bar, before the user presses enter, is it possible to "intercept" what they typed after they press enter?

You can't hook into what is typed in the address bar until the user submits it. Once the user submits text, you have two options:
If you're writing an extension, you can hook into an event when the url changes
Use window.location.href to pull the url of the page loaded in the browser.

var url = document.getElementById("urlbar").value;
That works, as does gURLBar.value.
The question is what context you run that code in. You should be running that code in a browser.xul overlay and after the browser DOM is loaded.
Also, yes it's possible to intercept what the user typed after they press enter, but there's not a public API for that, so you'd have to figure out how the relevant code in Firefox work and replace the part that's responsible for handling Enter in the location bar. [edit] see Firefox addon to do something everytime a user hits Enter in the address bar

getElementById gets a DOM element with the specified ID. The address bar isn't a DOM element.
You want:
var url = window.location;

The closest thing to what you want is window.location.href. However, it's not a perfect accessor for what is in the URL text box, as you will find that typing into the URL box but not pressing "enter" will not modify window.location.href. As far as I know, there is no way to access the text value directly.