Version: (using KDE 3.5.9) Installed from: SuSE RPMs location.replace() acts different under certain circumstances, especially with anchors. situation now: See the html snippet below, there you can find 3 cases: 1. replace with an external location everything seems fine 2. replace anchor (like location.href="#1") no href or address field update 3. replace anchor with location.pathname + anchor name history update, no difference to location.href="blabla" (just try the example to see what I mean) Shouldn't the behaviour always be the same in terms of history (no update) and address field / location.href (update)? Although location.replace() is not part of any formal specification I would appreciate a similar behaviour in all circumstances. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title></title> </head> <body> <div style="height:1000px"> <input type="button" value="to google" onclick="jump1()" /> <input type="button" value="#1" onclick="jump2()" /> <input type="button" value="document.location.pathname + #1" onclick="jump3()" /> </div> <a id="1" name="1"></a> <div style="height:50px;color:red;width:50px">anchor!</div> <script type="text/javascript"> // external location: replace works as expected (jumps to new site without history entry) function jump1() { document.location.replace('http://www.google.com'); }; // shorthanded anchor jump: window jumps successfully, no history entry // but address field/location.href doesn't change function jump2() { document.location.replace("#1"); }; // anchor jump with pathname: successful jump, appropriate address field/location.href update // but additional history entry function jump3() { document.location.replace(document.location.pathname + "#1"); }; </script> </body> </html>
Nice timing on this report --- I was just working on fixing issues related to this a few days ago, and was making a bunch of testcases trying to figure out what's expected. Thanks! > Shouldn't the behaviour always be the same in terms of history (no update) > and address field / location.href (update)? Although location.replace() is > not part of any formal specification I would appreciate a similar behaviour > in all circumstances. Other browsers don't handle them the same, actually. Basically, setting a hash happens immediately, while going to a URL happens after the script finishes running, so that: <script> document.location="http://www.kde.org"; document.location="http://techbase.kde.org"; </script> Goes to techbase.kde.org...
> Other browsers don't handle them the same, actually. Yes, you are right. I would go with the mozilla people, if I were you: no history update, but the location should change. Especially the not updated location of example 2 is annoying. (Case 3 was just a hack trial, to get case 2 working, I was really surprised to find a third way here.) > Basically, setting a hash happens immediately, while going to a URL happens after the script finishes running... Hm, from a browser developer's view I would guess the necessity of separating these newURL/anchor cases (since the doc is already loaded in the anchor case etc.), nevertheless for a webdeveloper the js-api should stay logic and predictable, and for location.replace() this would mean: 1. do what to do with the doc (either load new or jump to anchor) 2. update location (address field and so on) 3. don't even think about altering the history (important, otherwise replace() is much useless) This is just my opinion, but if you would ask others about location.replace(), they would answer in that way and most won't see any difference between location.replace('http://whole_new.site') and location.replace('#anchor') apart from a new page load in the former case. (I would like to have an "onAchor" event like "onLoad", but thats a diff. story.) Also I don't know if your example is related to the location.replace() stuff, but I think under the aspect of GUI responsiveness its quite good that way, since the script has time to finish afterwards. Regards, jerch
SVN commit 825638 by orlovich: Fix a number of issues related to redirections: - Strip leading # if given to location.hash, as other browsers do (part of #159192); avoids doubling it with various history frameworks, and stops confusing facebook's photo view (#165221) - Properly handle in-place redirects such as anchor jumps completely synchronously (part of #159192) - More importantly, don't handle in-place redirects as changing pages, which aborts parsing. Fixes some Wikipedia pages showing up blank. - Properly update history on anchor jumps, including honoring locking (#159279, #137176) Also, cleanup some of the handling of JavaScript URLs --- use the helpers I needed for above and not 10 different copies of string munging. BUG:165221 BUG:159192 BUG:159279 BUG:137176 M +14 -15 ecma/kjs_window.cpp M +72 -38 khtml_part.cpp M +23 -1 khtmlpart_p.h WebSVN link: http://websvn.kde.org/?view=rev&revision=825638