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: