IE11 and IFrame history object - javascript

We have an app with a list, that when a record is clicked a popup modal div is displayed, that is used to edit a user record. The div contains an iframe.
In the iframe, the user clicks save and the form is posted back, where server side validation occurs. If there is an error, the user is presented the error information and a go back button.
The go back button is wired to history.go(-1)
When it is clicked, in IE8/9/10 and Chrome, the iframe reverts back to the form with the user's changes still in it, allowing them to remedy any problems.
In IE11, it sends the parent page back to it's last page, so not only do you lose the div, but you lose the list.
Is there a way I can make IE11 behave like it was in IE10?
FWIW, we do perform basic client validation, such as checking for valid emails, mandatory fields etc, but we also do this in the backend, as well as checking that more complex rules to do with business relationships etc.
Thanks!

With IE11 finally going HTML5, you can save your history state so you would use push and popstate. Using this, you'll be able to control your "back" (working fine here).

Related

How to change the text on the page refresh message pop-up?

I have a web page that gets refreshed, when something happens on any of its children pages. When it happens, the IE pop-up appears with the following message: "To display the webpage again, the web browser needs to resend the information you've previously submitted. If you were making a purchase, you should click Cancel to avoid a duplicate transaction. Otherwise, click Retry to display". See the image attached:
I'm ok with all that, but I was wondering if there's a way to change the actual text of the message, for example, removing the last sentence. I know this pop-up can't be tampered with, but perhaps there's a way to replace it with a custom made pop-up, serving the same function, but showing a different text. I assume first I would have to suppress the original message, then call a confirm box in a beforeupdate function, where clicking OK (for example) would resend the information submitted and Cancel would let you remain on the page without refreshing it. However, my Javascript and JQuery knowledge is a bit rusty and I'm not sure how to implement it properly. Any help is appreciated.
Thank you

Display a customized confirm box in angularjs when user leaves a page

My requirement is to display a customized confirm box when the user leaves a page without saving form data.
I used the window.onbeforeunload event it is displaying google chrome related predefined confirm box. When the user changes any form and trying to reload, tab close or route change I want to display a $mdDialog.confirm and asking user to leave the page or stay on the same page. How do I make one?
For security reasons, this cannot be done. You can find more details in the MDN page on the beforeunload event.
In the past, you could return a custom string that was displayed to the user, but these days even that is ignore. The best you can do is instruct the page to show the standard dialog that you already have. (And in some browsers and some scenarios, even that instruction may be ignored.)
An alternative is to include a button in the page for leaving the form. Although that still does not prevent users from navigating away from the page directly, if it is sufficiently visible, in many cases users are more likely to click that than navigating directly. It also serves as a passive reminder that the form needs explicit saving or cancelling (depending on your specific details, of course).

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.

Safari Popup on tab close when submitting forms with AJAX

In Safari Browser, on a page with a form, there is a system modal popup that opens when the user tries to close the browser's tab and the form hasn't been validated. Text says: You have entered text on “[name of the page]”. If you close the window, your changes will be lost. Do you want to close the window anyway?
This behavior is ok when the post redirects to another the page. On our site, we have a page that validates a form using an Ajax Request. As the page is not reloaded, even if the form has been submitted, the popup appears, and it might feel strange for the end user.
The post is triggered by a button:
Forms are validated using the jQuery Validation plugin
Plugin options include a submitHandler option that return false;
Date are sent via $.post, and a message informs user for success/failure.
Does anyone have an idea about how to avoid this popup to be triggered once the call returns? We'd wish not to force a reload in that case.
Note that this behavior can be changed by the user, but not very easily...
I can't replicate this in Safari on Windows.
Maybe try emptying/resetting the input fields once the form has been submitted, only if there weren't any errors with the submission of course, or better yet, remove the form completely, if it's not needed after. Of course using DOM manipulation, not by reloading the page.
On a side note, seeing the filled-out form after it's been sent (even if you're showing a confirmation message) also can be strange for the user (unless it's a multiple-use form and this behaviour is expected).
UPDATE: tested on a Mac Safari, it's behaving as you described, but if I remove what I typed (that made the browser alert me in the first place), it doesn't come up. So, simple reset of the fields should do the trick.

Alternatives to disabling / disable back button in firefox and IE

Our application forbids going back for several reasons.
Basically because that's just how our application works (JSF with facelets as GUI)
You always have to enter on the welcome site, once you chose an application-flow you can only leave / abort when you tell the application (e.g. press a button). If you just browse away e.g. enter "example.com" in the address bar the state of your flow gets saved and once you relogin, you can resume the work. Going back is only possible when it was specifically designed like this with a 'back' submit - button.
Of course users keep pressing the 'back' button (i would do so as well) and they keep getting 'error: session out of synch'. This is a learning process and a couple years ago we just disabled the back-button to make things clear. Sadly this is no longer supported.
So instead of teaching the user the hard way and forcing him to relogin, are there some good alternatives I'm missing?
i found this link which should offer 3 methods to disable the back button - but in reality it just further confirms the fact that it is impossible to do it in a semi-nice way.
when the user tries to go to a previous page you can redirect him to the page he should be at in other words catch the "out of sync" and redirect him
You might find a workable solution here How do I insert an entry into browsing history via JavaScript
by inserting an extra step into the browser's history (perhaps a link to the current page with query string parameters that result in a nice big red box message to the user), or you could try attaching an event handler to the OnBeforeUnload event so the user gets a confirmation dialog when trying to leave the page (you'd want to remove the handler when the submit button was clicked).

Categories