Bug 3552 - Anomaly (infinite loop) with window.location.href='#foo'
Summary: Anomaly (infinite loop) with window.location.href='#foo'
Status: VERIFIED DUPLICATE of bug 7058
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 412
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Maciej Stachowiak
URL: http://www.s-seven.net/safari_bug.html
Keywords: HasReduction
Depends on: 7080
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-15 14:44 PDT by Benjamin Morin
Modified: 2006-02-08 11:09 PST (History)
2 users (show)

See Also:


Attachments
Code to demonstrate Bug 3552. (1.65 KB, text/html)
2005-06-15 14:58 PDT, Benjamin Morin
no flags Details
Another example of defect. (382 bytes, text/html)
2005-08-02 15:45 PDT, David Carson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Morin 2005-06-15 14:44:44 PDT
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
Comment 1 Benjamin Morin 2005-06-15 14:58:18 PDT
Created attachment 2375 [details]
Code to demonstrate Bug 3552.
Comment 2 Joost de Valk (AlthA) 2005-06-16 00:09:03 PDT
Confirmed, and an ugly one it is!
Comment 3 David Carson 2005-08-02 15:45:16 PDT
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.
Comment 4 Benjamin Morin 2006-01-17 09:33:04 PST
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.
Comment 5 Joost de Valk (AlthA) 2006-02-05 01:18:44 PST
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.
Comment 6 David Kilzer (:ddkilzer) 2006-02-07 21:21:25 PST
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 ***
Comment 7 Benjamin Morin 2006-02-08 09:38:47 PST
My test case is confirmed fixed with nightly r12598 or newer.
Comment 8 John Sullivan 2006-02-08 10:40:01 PST
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.
Comment 9 David Kilzer (:ddkilzer) 2006-02-08 11:09:01 PST
Verified by reporter.