In our web application, after the user logs on, we display a “Please wait…” screen and then the user is taken to the main screen, using a “location.replace(URL)” function call.
Yesterday, due to another problem, we noticed that when the user clicks the Back button on Internet Explorer (6 & 7), he is taken to the “Please wait” screen, and then back to the main window, instead of being taken to the login screen, since the “location.replace()” method promises according to all the documentation we found not to put the current page in the browser history object, so pressing the browser Back button should take you to the previous page.
Both my colleague and I put up a clean sample HTML files to test it, but where in my test page the problem didn’t re-occur, it did with my colleague HTML files. A little search for differences showed that I wrote a simple HTML page from scratch:
<html>
<body>
<form>
<input type=button value=click onclick=”location.replace(‘b.htm’)”>
</form>
</body>
</html>
But my colleague used a template to create her HTML file, so her files looked like:
<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>
<title>EXAMPLE</title>
</head>
<body>
<form>
<input type=button value=click onclick=”location.replace(‘b.htm’)”>
</form>
</body>
</html>
Checking it further, we found out that when you use location.replace (and also window.open with the last parameter set to true) and the page you switch to has a Content-Type http-equiv <meta> tag that has a charset setting in its content attribute, Internet Explorer for some reason adds the current page to the history object, so pressing the Back button will take you to that page.
Note that for the bug to happen the new page to which you replace need to have this <meta> tag, and the current page content has no affect. Also, you must set the charset in that page – setting a content type without a charset (e.g. “text/html;”) doesn’t cause the problem. Finally, setting the content type using a real HTTP response header and not using an http-equiv <meta> tag also doesn’t cause the problem.
The fix was simple as the page we were opening was actually a frameset, so the charset setting in it could be safely removed.
This is indeed an interesting bug, to which I found no reference on the web.
May 16, 2007 at 6:18 pm |
I encountered the same problem but having charset removed doesn’t help. I even removed the whole meta tag with content and got the same. IE still inserts the new URL into history. Firefox doesn’t
May 20, 2007 at 8:42 am |
Thank you Karen for your response.
Can you give a sample test case where I can inspect it and try to find what is wrong with your scenario?
Also, what version of Internet Explorer are you using?
As I said, in my tests, removing the charset solved the problem.
July 19, 2007 at 4:39 pm |
Hi Karen,
I think I understand where you are going wrong. I also faced the same issue that you were facing. I also removed the whole meta tag but didn’t work.
The mistake I was making was that I was removing the charset code & meta tag from the file which contained the location.replace code. Actually, what Spintor has noted is that you have to remove that code from the destination file of the replace.
I did that and it worked for me. :-)
BTW, Splintor, thanks a ton buddy. your is the ‘only’ post on the whole WWW that gave me my solution.
April 22, 2008 at 4:50 pm |
Hi,
i’m trying to switch to a pdf file. I can’t remove any tag from the pdf but the bug is still giving problems to me!!
Any ideas??
cheers
May 4, 2008 at 8:53 am |
Sorry Javi, I haven’t had this issue with a PDF file, only with HTML files with <meta> tags. I don’t know how to help you.
May 16, 2008 at 12:59 am |
Javi, you may want to look into using FlashPaper to show pdfs on your page
or
[not an "elite" workaround] use iFrame on the target page
in any case, after extensive experimentation, I concluded that injecting http headers doesn’t work, and it has to be an html page without a charset.
(I hope someone proves me wrong and finds another way)
Raine
September 28, 2008 at 10:13 pm |
I have discovered another IE7 bug for location.replace() (not related to the back button, though). If you specify a BASE HREF in the page that you are switching ~from~, IE7 ignores it when resolving the argument of location.replace() if that argument is a relative reference. The workaround, obviously, is to code an absolute reference, but of course this reduces the portability of the site.
December 15, 2008 at 7:19 pm |
I have an issue and believe location.replace would resolve. Can you see this and help me to resolve
there are 3 pages
Page 1 calls intermediate Page 2 which calls Page 3.
But if i click IE back button, the intermediate Page 2 should not be called and should go back to Page 1. Will this be achieved by location.replace?
December 15, 2008 at 10:00 pm |
@Mohan: You’ll have to provide a sample URL of what you are trying to do, so I can look at it and maybe see what you are doing wrong.