Browser, not engine ---> History: Session
Assignee: rogerl → radha
QA Contact: pschwartau → claudius
reporter (Jam): can you reproduce this bug with a recent build of mozilla (for example, 1.2.1)? if so, please comment again with details (attaching a testcase to the bug would make it easy to see how this works). if not, please resolve this bug as WORKSFORME. thanks.
history.go() is a function that takes a _number_ to go to in session history, relative to the current page. E.g. history.go(-1) to go back one page. So what you're doing is in fact not supposed to work; I wonder why you decided that it should...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: history.go() doesn't work → history.go(location) isn't implemented
Aiee. Punting over to DOM, I guess, to decide whether we want to support that....
Assignee: radha → general
Status: UNCONFIRMED → NEW
Component: History: Session → DOM: Level 0
Ever confirmed: true
OS: Windows NT → All
QA Contact: claudius → ian
Hardware: PC → All
Bummer this is here. I ran into the need for this badly today (using Moz 1.6). It is part of the JS 1.1 standard, at least according to my O'Reilly JS book; so I don't understand the comment "Punting over to DOM, I guess, to decide whether we want to support that". I suppose I'm assuming standard compliance is good, but isn't the only decision "when" or "what priority"? Pretending that I can carve out time for this, can someone point me to the proper directory where the history object code would be found? (or at least get me close :-)
Actaully, the Window object is not part of any standard... and JS 1.1 is not a standard, just a version of a language (of which Window is NOT a part). For anyone who feels like working on this, what would need to happen is that http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsHistory.cpp#243 (HistoryImpl::Go()) would need to detect a string argument in addition to the numeric one it detects now and it would need to call LoadURI on the webnavigation object the way HistoryImpl::Go(PRInt32 aDelta) does. Then nsSHistory::LoadURI would need to be implemented in some way at http://lxr.mozilla.org/seamonkey/source/xpfe/components/shistory/src/nsSHistory.cpp#635 (and deal with frames somehow... great fun).
I have an exit script which works in Netscape 7, IE6, which returns the user back to the original login page. <script> var loc1 = location.href; var endp = loc1.search(/logout/gi); var loc2 = loc1.substr(0,endp) + "index.asp" ; history.go(loc2) </script> renders the equivalent of history.go("http://10.1.1.1/index.asp") Have a new customer who wants to use FireFox as their default browser. My exit script won't work for him. Otherwise, everything else works great.
(In reply to comment #9) > I have an exit script which works in Netscape 7, IE6, which returns the user > back to the original login page. > > <script> > var loc1 = location.href; > var endp = loc1.search(/logout/gi); > var loc2 = loc1.substr(0,endp) + "index.asp" ; > history.go(loc2) > </script> > > renders the equivalent of history.go("http://10.1.1.1/index.asp") > Have a new customer who wants to use FireFox as their default browser. My exit > script won't work for him. Otherwise, everything else works great. > > > If you are using ASP your could try this: onClick="window.location='<%=Request.ServerVariables("HTTP_REFERER")%>'"
*** Bug 273655 has been marked as a duplicate of this bug. ***
*** Bug 275455 has been marked as a duplicate of this bug. ***
Wouldn't doing this leak history a tiny bit? In IE, window.history.go('http://www.mozilla.org/'); window.setTimeout("alert('clean')",2000); tells you whether someone has been traitorous in that session (assuming, of course, that instead of an alert it's an XMLHttpRequest resending a login cookie to identify who hasn't been bad).
*** Bug 279119 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > Wouldn't doing this leak history a tiny bit? Yeah, that was my first thought too. Though admittedly I was searching for a reason not to implement this :) In any case, there doesn't seem to be a whole lot of sites out there that use this. Regarding comment 10: You could simply do window.location = loc2;
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.