We aren't "compounding" frameset scrollbars

VERIFIED FIXED in M6

Status

()

Core
Layout: HTML Frames
P1
critical
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: Angus Davis, Assigned: karnaze (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: handing back (1223 fixed), URL)

(Reporter)

Description

20 years ago
This URL has a frameset like this:

 ---------
|___ A____|
|  |      |
|B |      |
|  |  C   |
|  |      |
-----------

Frame A should not have any scrollbars (has scrolling=no attribute)
Frame B should have auto scrolling
Frame C should also have auto scrolling. Frame C is the right most frame.

Becuase Frame C is along the right, it's scrollbar should be to the immediate
left of the Viewer's window border, where a normal scrollbar would appear.
Instead, the frameset document is getting a scrollbar all its own, and then to
the left of *that* scrollbar is another scrollbar for frame C!

You might need to resize (enlargen) the viewer window to see this bug.

I'm using 11-9-98 Optimized bits.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Assignee: karnaze → vidur
Severity: normal → critical
Status: ASSIGNED → NEW
Priority: P2 → P1
(Assignee)

Comment 1

20 years ago
I can't fix the bug because it is crashing in javascript. Please reassign it
back to me when the crash is fixed. I've cc'ed Rick G since the parser is in the
stack as well.

Updated

19 years ago
Assignee: vidur → fur

Comment 2

19 years ago
The script problem is because of bug 1223, assigned to fur@netscape.com. Since I
don't want to lose the original bug, I'm not resolving it as a DUP. I am,
however, assigning it to Scott so that he can return it to Chris Karnaze once
the bug is fixed.

Comment 3

19 years ago
Setting all current Open Critical and Major to M3

Comment 4

19 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Updated

19 years ago
Assignee: fur → mccabe

Comment 5

19 years ago
Same as #1223

Updated

19 years ago
Target Milestone: M3 → M4

Comment 6

19 years ago
lets try and get this for M4.

Updated

19 years ago
QA Contact: 4082 → 4110

Comment 7

19 years ago
re-assigning chrisd D as qa_contact.

Updated

19 years ago
QA Contact: 4110 → 3849

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 8

19 years ago
Setting this bug and friends to m5.  I hope to get to it soon.

(But I'm guessing it reflects a subtle change to the semantics of javascript
variable lookup, so I don't want to make that change without a full run of the
javascript testsuite.)

Comment 9

19 years ago
Whoops, actually changing the setting...

Comment 10

19 years ago
These bugs seem to be different aspects of 1223.  Shaver has graciously taken
1223; reassigning these to him.

(thanks, Mike)

Updated

19 years ago
Whiteboard: need status update

Updated

19 years ago
Target Milestone: M5 → M6

Comment 11

19 years ago
moving to m6

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Assignee: shaver → karnaze
Status: ASSIGNED → NEW
Whiteboard: need status update → handing back (1223 fixed)
1223 is fixed, so this is back to Chris.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

19 years ago
Fixed with recent checkins.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 14

19 years ago
tested and verified the fix.
You need to log in before you can comment on or make changes to this bug.