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

RESOLVED FIXED in mozilla0.9.1



19 years ago
8 years ago


(Reporter: stefan.huszics, Assigned: dr)




Firefox Tracking Flags

(Not tracked)


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


(5 attachments)



19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Win98; I)
BuildID:    2000061311


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

Comment 1

19 years ago
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 
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 2

19 years ago
First I'd like to apologize for apparently not beeing clear enough in my initial 

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:

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.


-----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. 


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.


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

[snip again]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"

Resolution: WORKSFORME → ---

Comment 3

19 years ago
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)
Severity: minor → critical
Ever confirmed: true

Comment 4

19 years ago
CC'ing Eric.  Any ideas on this one?

Comment 5

19 years ago
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

Comment 6

19 years ago
"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 
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 ;-)

Comment 8

19 years ago
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.

Comment 9

19 years ago
*** Bug 50429 has been marked as a duplicate of this bug. ***

Comment 10

19 years ago
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

Comment 11

19 years ago
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.


18 years ago
Keywords: donttest

Comment 12

18 years ago
Target Milestone: Future → mozilla0.8

Comment 13

18 years ago
Target Milestone: mozilla0.8 → mozilla0.9

Comment 14

18 years ago
->moz0.9.1, severity->normal (critical is for crash/data loss/severe leak)
Severity: critical → normal
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 15

18 years ago
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
I'm just affraid it will keep on beeing pushed towards the future indefinitly.

Comment 16

18 years ago
Ok I have a fix. Attached is the diff for nsCSSFrameConstructor and the testcase 
I used.

Comment 17

18 years ago
Created attachment 28199 [details] [diff] [review]
Diff for nsCSSFrameConstructor

Comment 18

18 years ago
Created attachment 28200 [details]
The test case

Comment 19

18 years ago
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.


18 years ago
Whiteboard: needs review

Comment 20

18 years ago
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.

Comment 21

18 years ago
Created attachment 28205 [details] [diff] [review]
nsViewportFrame diff

Comment 22

18 years ago
Assignee: evaughan → dr

Comment 23

18 years ago
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...
Whiteboard: needs review

Comment 24

18 years ago
Created attachment 34631 [details] [diff] [review]
Cleaned up patch

Comment 25

18 years ago
Created attachment 34632 [details]
Cleaned up testcase

Comment 26

18 years ago
Ok, I've attached a cleaned-up patch and testcase. Need r= and sr=.
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]

Comment 27

18 years ago
-r evaughan

Comment 28

18 years ago


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

Comment 29

18 years ago
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 30

18 years ago
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

Comment 32

18 years ago
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
Severity: normal → trivial
Priority: P3 → P5
Resolution: FIXED → ---
Target Milestone: mozilla0.9.1 → Future

Comment 33

18 years ago
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
Severity: trivial → normal
Last Resolved: 18 years ago18 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.