2.56 KB, text/plain
Browser, not engine. Reassigning to Embedding:Docshell for further triage. Confirming on WinNT, Linux with 2001-03-22 debug builds. OS Solaris --> All. On WinNT, I get this dialog over and over: ###!!! ASSERTION: The DocLoader is still busy... There is a bug in End Document notifications: '0';, file d:\mozilla\xpfe\browser\src\nsBrowserInstance.cpp, line 998
Assignee: rogerl → adamlock
OS: Solaris → All
QA Contact: pschwartau → adamlock
Hardware: Sun → All
Probably the line that says "searchbar.history.go(0)" in the page source has something to do with it. CC'ing Radha.
Target Milestone: --- → mozilla0.9.1
This bug displays the JS history mechanism that was changed for the 6.0 release. In the previous releases, each frame had its own history and anything like <framename>.history.go() would exercise only the local frame history. But for Netscape 6, for modularity reasons, we decided to let go of the frame specific history (which I guess was introduced in 3.0 release) and tie all history transactions in subframes to the main SH of the browser window. Therefore the search.history.go(0) which in the previous release would have affected just that frame now does a reload on the whole page and therefore the infinite loop. I think changing searchbar.history.go(0) to a searchbar.location.reload() which will trigger a reload only in that frame will fix the problem.
So what's the answer for this? Should this bug be marked WONTFIX, or do we need to consider making go(0) a no-op?
This should be a won't fix. Changing history.go(0) to a no-op will have bad side-effects
Marking WONTFIX. Remove the history.go(0) in the code to avoid reloads.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Replacing the history.go(0) call with a location.reload() should work fine without causing a infinite loop.
*** Bug 122811 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.