In Safari 1.3/2.0 and Safari 2.0 using the latest CVS WebKit as of this report, executing the javascipt window.location.href='#foo' causes the activity indicator to spin constantly, even though the page appears to have loaded successfully and works as designed. This is especially visible when tabbed browsing is enabled as there is an activity indicator on the tab. It also appears that the "Stop" toolbar button never turns back into the "Reload Page" button. While this is happening, if you select "Reload Page" from the "View" menu, it appears as though the page attempts to load over and over again. Steps to Reproduce: Create an html document with the following: <html><body> <h3 id="h_value">h_value</h3><p>This is under h_value</p> <script type="text/javascript">window.location.href='#h_value';</script> </body></html> Expected Results: The page should load and the activity indicator should stop spinning. Actual Results: The page loads and the activity indicator does not stop spinning and if reload page is selected from the view menu, the page loads in an infinite loop. Regression: The problem did not exist in Safari 1.2.4. Notes: An online example can be seen at http://www.s-seven.net/safari_bug.html
Created attachment 2375 [details] Code to demonstrate Bug 3552.
Confirmed, and an ugly one it is!
Created attachment 3210 [details] Another example of defect. Similarly, you can't access the DOM after a call to location.hash. See attachement. If a style is added, such as: <style> DIV.t:first-letter {text-transform:uppercase;} </style> Safari will crash as it tries to update a DOM element that has disappeared.
UPDATE: In WebKit SVN r12148, though there is nothing to indicate a change specific to this bug, hitting the "Stop" button or selecting the "Stop" menu item does stop the activity indicator and selecting the "Reload" page menu item doesn't seem to create the infinite loop, though the progress indicator doesn't stop on page load as it should indicating that there is still a problem here.
The infinite loop part of this was filed as bug 7080, to be able to fix both the root cause of this bug and the fact that it goes into an infinite loop.
This bug was fixed with the commit for Bug 7058 (confirmed locally by applying the patch in reverse and rebuilding r12652), so marking it a duplicate of that bug. Bug 6309 was also fixed at the same time. Reporter, please verify that this was fixed with nightly r12598 or newer. Should a test case be prepared and checked in for WebKit to make sure this doesn't regress? *** This bug has been marked as a duplicate of 7058 ***
My test case is confirmed fixed with nightly r12598 or newer.
Wow, what a pleasant surprise that this older bug was fixed by the change for 7080. The intention of 7080 was to reverse a regression caused by a very recent code change, so it's a surprise that it fixed any older case. I guess the new Timer reorganization that led to 7080 improved something about the flow of control here such that, when 7080 was fixed, some old problems were also fixed.
Verified by reporter.