I'm using asp.net webforms, so every server control generates post request on click. If I try to reload page with F5 or Ctrl+R after that request, browser by default shows re-post warning.
To avoid this behavior in IE 7-* I tried this solution: Unable to disable F5 key in IE8
But there is still warning in IE8 after post, whereas after get request all right.
How to deal with it?
You really shouldn't disable the F5 key or the browser back button as this is breaks the user mental model of how the browser works (and this is a bad thing).
The post warning is important because you really are POSTING the data back to the server (if this was after posting a record to a shopping cart) then you would submit the purchase again or add the previously added record to the database again.
It would be better to provide them with a clear and obvious way for them to get updates to the page when then require them.
A suggestion
If you just want to refresh the page to see the contents of an updated table or list or to get the latest status after the post then you could provide a button or link on the page that the user can click that preforms a AJAX get for the information that you requires and then just update the part of the screen that you need to redisplay.
You could also also do this with a SetTimeout so that the page / data updates in the background without the need for the user to click on a button or link.
Related
I am trying to add a onbeforeunload to my code so it fires a message that is sent to a server. I am encountering the following issue:
On page refresh, the message is sent to the server when using Firefox. It does not send a message to the server when I refresh the page on Google Chrome.
When clicking on links on my site to navigate to different sites, the server gets a message only when using Chrome. Firefox does not send a message when clicking on external links.
I also know that onbeforeunload is supposed to work when the window is closed, you enter a different website and navigate to that. There are some additional cases which also trigger the function. My site does not work with any of these along with the errors mentioned above.
If there a fix to this? If so, what can I do? I have looked around to fixes but I only get fixes where it prompts the user on whether they want to leave the page or not, I do not want that.
Additionally, I tried adding the function call to onclick on my external links but that is not being triggered on Firefox. I am guessing this is due to the amount of time onbeforeunload has before it is cancelled. If so, there a way around this?
Lastly, if this is not possible with onbeforeunload, what are my other options without prompting the user if they want to leave or not.
Thanks in advance!
EDIT: Here is some code that can be used:
https://jsfiddle.net/985drboy/
Make sure, that your code sending the message to the server is blocking and not async. If onbeforeunload returns before your message is sent, you get undefined behavior e.g. your message might not be sent if the page is unloads before the sending was complete. The browser continues unloading as soon as unbeforeunload returns.
On a real estate website I'm working on I have a Contact Us form on the Property Details page where the user can click the Contact Us button, which will load the form in a modal dialog, an iframe loading the contact us form, fill in some details and send it off.
Once the form has been processed server side I have to emit JavaScript code from the server that calls the dialog close method and then redirects the user to a thank you page (If I did a simple redirect on the server the iframe would get the thank you page which I don't want).
The problem is in Chrome where if you hit the Browser's back button the contact form is quietly resubmitted.
Note: IE and Firefox don't have this issue at all.
I found the following links useful, but not the answer to my problem:
https://productforums.google.com/forum/#!topic/chrome/J1KMARIIHW4
https://code.google.com/p/chromium/issues/detail?id=263508 (this one seems very close to the behaviour I'm seeing - but it seems like a bug that has continually resurfaced over the last couple of years)
Chrome executing all JS again on browser back button
We've tried various techniques to circumvent the issue in Chrome like hidden fields, insured cache is turned off, destroy the iframe before redirecting to the thank you page. Nothing it keeps resubmitting the form without even asking if you want to resubmit (not that it should be resubmitting at all)
Just come across this issue, what I'm thinking of doing is including some sort of one-time token (i.e. GUID) in the form, which if we re-detect on the server we can ignore the form post. Possibly use session state on the server to keep track - much like a Rails authenticity token
I am currently trying to manually develop an unsaved changes warning in our JSF-based Webapplication. Sadly our customer does not like the styling of the default warning displayed via an alert() after using the onbeforeunload event and requires us to develop a similar mechanism on our own.
I was thinking of using the way described here to prevent the onbeforeunload event from displaying the alert() and simply showing my own modal panel. I just can't figure out how to make the "Yes" (yes, I want to leave this page and lose all unsaved changes) button work. The button should basically resend the request which lead to the onbeforeunload event which could have been a HTTP Request as well as an Ajax Request. How would one do that via JS?
Thank you :)
Cheers
//edit: It needs to work in IE9 as well as Chrome 38
I have been thinking about this but can't figure out due to lack of familarity with how actually facebook is designed to work. If you can help and point me in right direction that would be helpful.
Problem: If you are at a group page and someone post a message you have to reload the page to see the new post. Which is annoying if it turns into chatting.
Possible solutions: that i've come up with..
extension detects new notification...somehow decide if it's about the page we are at, if yes then in background load the page get the new data and add the stuff to the page already opened. (don't know if it's even possible with the extension)
2nd idea is load after detection and confirmation just reload the page and retain all text that's been written and just scroll to that post again. I inspected the post structure it all looked randomly generated string...couldn't tell if any of the class or id were reliable to identify the textbox.
3rd idea is make new page bottom up that relies on some sort of sdk and updates pages as new post come in..(least favorable to me).
4th idea is forget about retaining the text that has been typed, if all inputs are empty and there is new notification reload the page...( i really wish reloading wasn't involved.
You can use the Javascript SDK and an AJAX post. When the server responds, if nothing extraordinary happened (no access token is expired, your facebook app is allowed), then you can handle whatever you want in the callback.
This is not a Meta question.
I am trying to technically understand what principle is hidden behind the following behaviour. It's very easy to reproduce:
Vote up/down anything on this page1,
Click on any other link on this page,
Come back by pressing the back button.
Your upvote is not there anymore as well as any AJAX activities having appeared on the page.
Why is that? Why is the browser acting like so? How could StackOverflow prevent that?
1 If you are not connected, just wait for someone else's activity on the page (new comment, answer, vote) before moving page.
It’s the browser’s cache that is at play here.
Since you’re asked how SO could “prevent” this, it could be done by advising the browser to check for whether the document has changed every time. But SO not doing so, for performance reasons. So the HTML document is seen as “still valid” for a certain amount of time, during which the browser takes it straight from its cache, without making a round-trip to the server.
If you look at the HTTP response headers in your browser’s developer tools for the request your browser made for this page, you will see something like this,
Cache-Control: public, no-cache="Set-Cookie", max-age=60
– so this HTML document is to be considered valid for 60 seconds. If you navigate away from it and back in your browser, or close the tab and reopen it from history, within that 60 seconds, the browser is supposed to take the cached version of it and display it, without checking again with the server whether or not something has changed. And since your vote did not manipulate this original HTML document (only the DOM was updated with your vote), you still get the previous vote count shown.
But if you press [F5] in your browser, the cache will be circumvented – it will request the document from SO again, and then you see your vote, because this time the updated numbers are part of the updated HTML document that SO serves you.
If you want to delve more into HTTP caching, some resources of the top of Google that seem worth a look:
Caching Tutorial for Web Authors and Webmasters
A Beginner's Guide to HTTP Cache Headers
You are not "unvoting", you just are not seeing your vote because your browser is caching the ajax request.
If your press F12 on Chrome, click on Settings icon and then "Disable cache (while DevTools is open)", when you press back the browser will resend the request.
To prevent that you must specify on your code that you never want that specific request to be cached.
You may want to check the following post:
Prevent browser caching of jQuery AJAX call result
-
Ps. You must stay with the Console (F12) opened while doing the test.