You need to
before you can comment on or make changes to this bug.
Changing the location hash on a frameset causes the frameset to reload. This occurs whether the hash is changed manually or programmatically by setting window.location.hash.
Firefox and IE do not exhibit this behavior; neither non-frameset pages nor frameset pages reload when the hash is changed.
This is troublesome for trying to maintain state by setting the hash.
Reduction is available at http://pilgrimwebdesign.com/changehash.html. This is a frameset containing only one frame. That frame displays new Date().getSeconds(). It also kicks off a timeout for 5 seconds to set the top's hash value. The result in WebKit is that the whole page reloads every 5 seconds, and one can observe the value displayed in the frame changing. In Firefox and IE, no reload happens.
I have reproduced this in the current nightly, in Safari 3.1.2, and in Chrome.
Created an attachment (id=28585) [details]
I have same problem too, waiting for immediate action...
Same problem here. Frameset based page, using hash to navigate. Safari and chrome doesn't work properly. Though sometimes there is a workaround but overall it increases the development and maintenance time.
Example page: http://www.utopicfarm.com/tolga/hash/
Created an attachment (id=52828) [details]
Display the reload event when the location.hash is changed.
Same bug here.
Is it possible to assign this light bug to somebody ?
The current behaviour is caused by FrameLoader::shouldScrollToAnchor
Scrolling to an anchor is explicitly excluded for a frameset, the reason is given in the comments: "we don't want to just scroll if a link from within a frameset is trying to reload the frameset into _top."
In Firefox a link from within the frameset can reload the frameset, but only as long as the link contains no hash.
ie <a href="index.html" target="_top">Reload!</a>
will reload the frameset
but <a href="index.html#" target="_top">Reload!</a>