Closed Bug 233963 Opened 20 years ago Closed 20 years ago

[FIX]Javascript location.href="#foo" causes window contents to fail to appear.

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8alpha1

People

(Reporter: r-scott.butler, Assigned: bzbarsky)

References

Details

Attachments

(2 files)

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>Test Script</title>
</head>
<body>
<SCRIPT> window.location.href="#A"; if(window.scrollTo) scrollTo(0,0); </SCRIPT>
<h1>Header</h1>
<p>A paragraph of text.</p>
<p>A second paragraph.</p>
</body>
</html>


If the HTML above is loaded into any of the Gecko-based browsers, the result is
a blank page. That is, no text appears.  On IE or Netscape 4.x, the 'Header'
line and paragraphs appear. 

Just FYI, the javascript above is a simplified version of the following obtained
from an actual application:

<SCRIPT> window.location.href="#A"; if(window.scrollTo)
scrollTo(0,(document.body ? document.body.scrollTop : pageYOffset) - 20); </SCRIPT>


Reproducible: Always
Steps to Reproduce:
1. view the HTML above in Mozilla 1.6, Firebird, or Nescape 7.1
2.
3.

Actual Results:  
<< a blank screen>>

Expected Results:  
Header
A paragraph of text.

A second paragraph.


The behaviour occurs on both Linux and Windows (XP and 2000) systems.
nsLocation::SetHref calls Stop() (with STOP_CONTENT).  I assume that's needed
for cases when we actually plan to load a new URI?  But in this case, we just
stop the content and then do a scroll, which means we show no content...
Assignee: general → general
Component: JavaScript Engine → DOM: Level 0
OS: Windows 2000 → All
QA Contact: pschwartau → ian
Hardware: PC → All
Summary: Javascript 'scollTo' causes window contents to fail to appear. → Javascript location.href="#foo" causes window contents to fail to appear.
*** Bug 242913 has been marked as a duplicate of this bug. ***
OK, it looks like the code in bug 37434 did some content-stopping inside
docshell, presumably _after_ we'd tried scrolling.  Then it was converted to
unconditional Stop() calls.  Bug 114975 fixed setting location.hash, but
location.href still stops content.
Assignee: general → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Summary: Javascript location.href="#foo" causes window contents to fail to appear. → [FIX]Javascript location.href="#foo" causes window contents to fail to appear.
Target Milestone: --- → mozilla1.8alpha
Comment on attachment 148028 [details] [diff] [review]
Special-case location.href='#foo'

The other options would be to move the stopping back down into docshell or to
have code here that tries to figure out whether we just plan to scroll
(duplicating code in docshell).  Both of those solutions would work for all
scrolling cases, thought, whereas this just fixes this special case....

I really wish we had better ways of comparing two URIs.  :(
Attachment #148028 - Flags: superreview?(jst)
Attachment #148028 - Flags: review?(jst)
Comment on attachment 148028 [details] [diff] [review]
Special-case location.href='#foo'

+    // Special-case anchor loads so that we don't stop content
+    nsAString::const_iterator start, end;
+    aHref.BeginReading(start);
+    aHref.EndReading(end);
+    ++start;

nsStandardURL::SetRef() already does this, so you don't need to duplicate this
code here.

r+sr=jst
Attachment #148028 - Flags: superreview?(jst)
Attachment #148028 - Flags: superreview+
Attachment #148028 - Flags: review?(jst)
Attachment #148028 - Flags: review+
Checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: