Summary: | [testcase] javascript location.replace anchor problem | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | jerch <brejoe> |
Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | maksim |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
jerch
2008-03-14 02:14:24 UTC
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 |