Closed Bug 46287 Opened 24 years ago Closed 23 years ago

<frame scrolling="no"> breaks window.scroll and html anchors

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: stefan.huszics, Assigned: dr)

References

Details

(Keywords: testcase, Whiteboard: [Have reviewed fix, ready for checkin])

Attachments

(5 files)

Diff for nsCSSFrameConstructor
4.78 KB, patch
Details | Diff | Splinter Review
The test case
1.34 KB, text/html
Details
nsViewportFrame diff
1.51 KB, patch
Details | Diff | Splinter Review
Cleaned up patch
5.84 KB, patch
Details | Diff | Splinter Review
Cleaned up testcase
350 bytes, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Win98; I)
BuildID:    2000061311

<FRAME SCROLLING="NO">

HTML 4.01 Definition: SCROLLING="no": This value tells the user agent not to 
provide scrolling devices for the frame window. 

Mozilla M16: blocks scrolling altogether i.e. e.g. doesn't allow "jumping" to 
ID="abc" via HREF="#abc" (TARGET="_self").

example file at http://members.xoom.com/_XMCM/huszics/navbarM.html
If put in a scrolling="no" frame it fails to "jump" to the location of the ID.

Reproducible: Always
Steps to Reproduce:
1.Pleas read above
Note: please remove doctype html 4.0 as it is not strict 4.0 html and will 
render incorrectly with such a declaration sorry.
I downloaded a copy of this webpage, made the change myself and tried the page, 
and the jumping works just fine (it fact its kinda neat!:)
testing in 2000.07.17.08 marking WORKSFORME.  Reporter please try a new nightly 
build, then if you still are seeing this (after removing your doctype) please 
reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
First I'd like to apologize for apparently not beeing clear enough in my initial 
bugreport.

The page http://members.xoom.com/_XMCM/huszics/navbarM.html render and "jumps" 
correctly ON IT'S OWN (even with doctype set).

The problem arizes when it is put into an SCROLLING="NO" frame.
I've added two more links to show this:
http://members.xoom.com/_XMCM/huszics/index.html
http://members.xoom.com/_XMCM/huszics/index2.html

The latter does not include doctype (neither index2.html or navbarM2.html)
just to show that this has no effect on this issue what so ever.

If SCROLLING is set to "AUTO" or "YES" in index/index2 for the frame, it however 
will "jump" correctly (but you will also have an ugly scrollbar to the left).

This is tested with both M16 and 2000072108 (currently I cannot download the 
lastest nightly build to test, download stalls at just over 50% and since I'm on 
a modem connection I haven't tried more then twice).



Additionally I would like to comment on

"Note: please remove doctype html 4.0 as it is not strict 4.0 html and will 
render incorrectly with such a declaration sorry."

I've noticed that Mozilla currently doesn't render pages correctly with doctype 
set (thanks btw, removing it cleared up a lot of rendering issues on some of my 
pages). However I do not agree with "...it is not strict 4.0 html...", rather 
the opposite. 
Please read below, I've marked the key statements with [!!!]. If I somehow have 
missinterpreted what it sais I again apologize, otherwize this will lead to 
another bug report concerning the incorrect rendering issue. 

Waiting to hear back from you.

Sincerly
Stefan


-----Taken from HTML spec 4.01 @ W3C----

7.1 Introduction to the structure of an HTML document
An HTML 4 document is composed of three parts:

a line containing HTML version information, [!!!]
a declarative header section (delimited by the HEAD element), 
a body, which contains the document's actual content. The body may be 
implemented by the BODY element or the FRAMESET element. 

[snip]

7.2 HTML version information
A valid HTML document declares what version of HTML is used in the document. The 
document type declaration names the document type definition (DTD) in use for 
the document (see [ISO8879]).

HTML 4.01 specifies three DTDs, so authors must[!!!] include one of the 
following document type declarations in their documents.

[snip]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">

[snap]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">

[snip again]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
        "http://www.w3.org/TR/html4/frameset.dtd">

-----------------
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Ok I'm seeing this, now. Marking New,  Seems pretty severe marking critical, put
the proper url for seeing the problem in URL bar.

Will email you with a basic explanation of the doctype problem. (later)
URL: See below → http://members.xoom.com/_XMCM/huszics...
Severity: minor → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
CC'ing Eric.  Any ideas on this one?
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
"Will email you with a basic explanation of the doctype problem. (later)"

Thank's but I figured out the problem my self. I missunderstod your earlier 
statement. I know see that you meant that my .html "didn't comply to the 
strict.dtd", not that "doctype should not be included" as I first interpreted it 
as.
This however have left me a bit puzzled about how to make a framebased site 
without using loose.dtd, which W3C advice against if it can be avoided :-).
Guess their currently reworking the entire href/LINK part of HTML or something. 

"If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
"
Since I'm not a programmer I cannot help in fixing it, however, the issue is 
quite easy to work around in the meantime (if you are aware of it), just set 
scrolling= yes or auto.

(This post is obviously meant as a quick help for others beeing affected by this 
bug and not me telling NS people how to write an webpage ;-)
When scrolling is defined in the frame element as scrolling="no", scrolling is
also impossible using script window.scroll(x,y), while per definition only the
scrollbar should be invisible.
*** Bug 50429 has been marked as a duplicate of this bug. ***
Reassigning to the scrolling guru, Eric Vaughan - this sounds like a problem
with the way we implement scrolling=no.  We should probably still allow the page
to be scrollable, but just not draw any scrollbars.
Assignee: pollmann → evaughan
Component: HTMLFrames → Layout
OS: Windows 98 → All
Hardware: PC → All
Summary: SCROLLING="NO" doesn't allow "jumping" to ID="abc" via HREF="#abc" → SCROLLING="NO" doesn't allow jumping to named anchors or window.scroll
I don't know if this is the same bug but on M18 on Linux Mozilla will not follow
any relative links in a JavaDoc page. For example, goto a Javadoc page for a
class @ java.sun.com and click on a link for a method in the current class under
"Method Summary" nothing happens.
Keywords: donttest
targeting
Target Milestone: Future → mozilla0.8
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9
->moz0.9.1, severity->normal (critical is for crash/data loss/severe leak)
Severity: critical → normal
Target Milestone: mozilla0.9 → mozilla0.9.1
Isn't severity Normal a bit on the lowseide though, considering that this
potentially blocks access to entire sites if they use the related way of site
navigation.
I'm just affraid it will keep on beeing pushed towards the future indefinitly.
Ok I have a fix. Attached is the diff for nsCSSFrameConstructor and the testcase 
I used.
Status: NEW → ASSIGNED
Attached file The test case — 

    
    

    
  
Fix description:

Normally when scrolling is "yes" a gfxscrollframe is created that contains a 
scrollport. Then the children go inside the scrollport. The gfxscrollframe 
contains the scrollbars. The scrollport allows scrolling. To fix this I changed 
it to create only the scrollport if scrolling="no". This allows the area to be 
scrolled but does not provide scrollbars. And this fixes the problem.



    
  
Whiteboard: needs review

    
    

    
  
Opps forgot to add a file. nsViewPortFrame was asking the scrollview for the 
size of the scrollbars but in the GFX world the views don't know how big the 
scrollbars are. So It needed to go through the XP interface nsIScrollFrame.



    
    

    
  


  

    
    

    
  
->dr
Assignee: evaughan → dr
Status: ASSIGNED → NEW

    
    

    
  
this patch is fairly bitrotted... i think robert o'callahan checked in a variant
of the nsViewportFrame.cpp patch, so i shouldn't need that at all... as for
nsCSSFrameConstructor, my life would be *much* easier right now if you'd have
posted a unified diff (diff -u), eric... now i have to go rummage through bonsai
to see what it was you were trying to do...
Status: NEW → ASSIGNED
Whiteboard: needs review

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Cleaned up patch
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Cleaned up testcase
        — 
      

    


  

    
    

    
  
Ok, I've attached a cleaned-up patch and testcase. Need r= and sr=.
URL: http://members.xoom.com/_XMCM/huszics...
Keywords: donttest → approval, 
          
            patch, 
          
            review, 
          
            testcase
Summary: SCROLLING="NO" doesn't allow jumping to named anchors or window.scroll → <frame scrolling="no"> breaks window.scroll and html anchors
Whiteboard: [fix in hand]

    
    

    
  
-r evaughan

    
    

    
  
sr=hyatt


    
  
Whiteboard: [fix in hand] → [Have reviewed fix, ready for checkin]

    
    

    
  
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
This is a frameset issue so changing QA to amar

QA Contact: petersen → amar

    
    

    
  
 The fix checked in works fine. Marking verified
Build ID# 2001-07-06-0.9.1
Status: RESOLVED → VERIFIED

    
    

    
  
Sorry, but I must reopen the bug again.

In general everything works as intended (thanks to everyone involved), just for
one small inconsistency.


Focusing on a frame with scrolling="no" will allow you to scroll it up and down
via Page up/down & Home/End.
Arrow up or down (and presumably left n' right) however will NOT scroll it.

Expected behaviour: Consistency (ie either scroll or don't).

Personally I suggest (keeping with the definition that only the scrollbars them
selfs should be removed by scrolling="no") that all of keys should allow for
scrolling the area (ie the arrow keys are currently broken).

Setting P5 & trivial since this is just a really small flaw that preferably
should be fixed sometime in the future. Of course if someone already knows where
the problem is and how to solve it and only need 5 minutes to fix it ... =)

Anyway thanks for your time

/Stefan Huszics
URL: http://hem.bredband.net/stehus/indexe...
Severity: normal → trivial
Status: VERIFIED → REOPENED
Priority: P3 → P5
Resolution: FIXED → ---
Target Milestone: mozilla0.9.1 → Future

    
    

    
  
Stefan: the symptoms you report are different from this bug. No sense reopening
it. Please open a new bug describing the regression you see now, to component
HTMLFrames.
URL: http://hem.bredband.net/stehus/indexe...
Severity: trivial → normal
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Priority: P5 → P3
Resolution: --- → FIXED
Target Milestone: Future → mozilla0.9.1

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: