Bug 56204 - Cannot move back to pages which were left using window.location
Summary: Cannot move back to pages which were left using window.location
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: kjs (show other bugs)
Version: 4.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-21 12:15 UTC by Antiphon
Modified: 2003-11-12 19:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antiphon 2003-03-21 12:15:06 UTC
Version:           4.0 (using KDE 3.1.1)
Installed from:     (3.0)
Compiler:          gcc version 2.95.4 20011002 (Debian prerelease)
OS:          Linux (i686) release 2.4.20

Try clicking on a link which uses the JavaScript window.location method to redirect the user to another page. You will not be able to press back to return to the original page.

This bug previously occurred in the 3.0.y series but has since resurfaced. 

Many sites use this method so I think it's pretty serious.
Comment 1 Antiphon 2003-03-21 12:17:52 UTC
Oops, should be moved to kjs 
Comment 2 David Faure 2003-03-24 13:35:29 UTC
OK I see the bug now. I thought "can't go back" was due to a re-redirection. 
No, it's just that "Back" is disabled ;) 
Comment 3 David Faure 2003-03-24 13:50:09 UTC
Subject: KDE_3_1_BRANCH: kdelibs/khtml/ecma

CVS commit by faure: 

Don't lock history when executing window.location='...', one wants to be able to go back.
Only location.replace locks the history.
CCMAIL: 56204-done@bugs.kde.org


  M +1 -1      kjs_html.cpp   1.224.2.10
  M +1 -1      kjs_window.cpp   1.299.2.13
  M +1 -1      kjs_window.h   1.88.2.4


--- kdelibs/khtml/ecma/kjs_html.cpp  #1.224.2.9:1.224.2.10
@@ -419,5 +419,5 @@ void KJS::HTMLDocument::putValueProperty
     KHTMLView *view = static_cast<DOM::DocumentImpl*>(doc.handle())->view();
     if ( view )
-      Window::retrieveWindow(view->part())->goURL(exec, value.toString(exec).qstring());
+      Window::retrieveWindow(view->part())->goURL(exec, value.toString(exec).qstring(), false /*don't lock history*/);
     break;
   }

--- kdelibs/khtml/ecma/kjs_window.cpp  #1.299.2.12:1.299.2.13
@@ -704,5 +704,5 @@ void Window::put(ExecState* exec, const 
     }
     case _Location:
-      goURL(exec, value.toString(exec).qstring());
+      goURL(exec, value.toString(exec).qstring(), false /*don't lock history*/);
       return;
     case Onabort:

--- kdelibs/khtml/ecma/kjs_window.h  #1.88.2.3:1.88.2.4
@@ -94,5 +94,5 @@ namespace KJS {
     void delayedGoHistory(int steps);
     void goHistory(int steps);
-    void goURL(ExecState* exec, const QString& url, bool lockHistory = true);
+    void goURL(ExecState* exec, const QString& url, bool lockHistory);
     Value openWindow(ExecState *exec, const List &args);
     void resizeTo(QWidget* tl, int width, int height);


Comment 4 Vedran Ljubovic 2003-11-12 19:50:01 UTC
David Faure wrote:
> Only location.replace locks the history.

What is the rationale behind this? Why shouldn't location.replace update the history? I was about to report it as bug but found this report. The script used by most sites here as a generic "JavaScript jump" script uses location.replace(url) if IE is detected, and location.href = url otherwise. Is there a better suggestion?