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)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla0.9.1
People
(Reporter: stefan.huszics, Assigned: dr)
References
Details
(Keywords: testcase, Whiteboard: [Have reviewed fix, ready for checkin])
Attachments
(5 files)
4.78 KB,
patch
|
Details | Diff | Splinter Review | |
1.34 KB,
text/html
|
Details | |
1.51 KB,
patch
|
Details | Diff | Splinter Review | |
5.84 KB,
patch
|
Details | Diff | Splinter Review | |
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
Reporter | ||
Comment 2•24 years ago
|
||
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)
Severity: minor → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•24 years ago
|
||
CC'ing Eric. Any ideas on this one?
Comment 5•24 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
Reporter | ||
Comment 6•24 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 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 ;-)
Reporter | ||
Comment 7•24 years ago
|
||
Changed link to new current position http://members.xoom.com/_XMCM/huszics/bug/frame_scroll_no.html Working (ie scrolling="yes") still at http://members.xoom.com/_XMCM/huszics/index.html
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 10•24 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•24 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.
Comment 14•24 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
Reporter | ||
Comment 15•24 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 navigation. I'm just affraid it will keep on beeing pushed towards the future indefinitly.
Comment 16•23 years ago
|
||
Ok I have a fix. Attached is the diff for nsCSSFrameConstructor and the testcase I used.
Status: NEW → ASSIGNED
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
Comment 19•23 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.
Updated•23 years ago
|
Whiteboard: needs review
Comment 20•23 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•23 years ago
|
||
Assignee | ||
Comment 23•23 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...
Status: NEW → ASSIGNED
Whiteboard: needs review
Assignee | ||
Comment 24•23 years ago
|
||
Assignee | ||
Comment 25•23 years ago
|
||
Assignee | ||
Comment 26•23 years ago
|
||
Ok, I've attached a cleaned-up patch and testcase. Need r= and sr=.
Comment 27•23 years ago
|
||
-r evaughan
Comment 28•23 years ago
|
||
sr=hyatt
Updated•23 years ago
|
Whiteboard: [fix in hand] → [Have reviewed fix, ready for checkin]
Assignee | ||
Comment 29•23 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 30•23 years ago
|
||
This is a frameset issue so changing QA to amar
QA Contact: petersen → amar
Comment 31•23 years ago
|
||
The fix checked in works fine. Marking verified Build ID# 2001-07-06-0.9.1
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 32•23 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
Status: VERIFIED → REOPENED
Priority: P3 → P5
Resolution: FIXED → ---
Target Milestone: mozilla0.9.1 → Future
Assignee | ||
Comment 33•23 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 HTMLFrames.
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.
Description
•