Closed Bug 233963 Opened 21 years ago Closed 21 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8alpha1

People

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

References

Details

Attachments

(2 files)

Nothing to do with scrollto
81 bytes, text/html
Details
Special-case location.href='#foo'
1013 bytes, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review
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: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: