Jan. 22 build. At www.stocksite.com, two scroll bars, instead of one, show up on the right. It appears to be one for each vertical frame. This does not happen on windows, though it does happen on Unix.

Inserting Milestone info.

Setting all current Open/Normal to M4.

Definitely lays out weird. Throwing to component owner with a CC: to pierre.

paulmac, please try with latest build - all platforms.

yep, still having problems on Unix. It's a little better, in that there's still two bars on the right, but you can only scroll on one of them. Same behavior on PC also now, so removing [PP}. (Mac dead right now).

On Win32, there is only 1 scrollbar but there is a black area to the right of it. Upon resizing the viewer, the page looks ok. Will look at later.

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

Here is a simple test case. I have a solution and am waiting for approval from Troy. --- bug2620-1.html--- <frameset rows="*" framespacing=0 frameborder="no" border=0> <frame src=bug2620-2.html marginwidth=0 marginheight=0></frame> </frameset> --- bug2620-2.html <frameset rows="*" framespacing=0 frameborder="no" border=0> <frame src=hello.html marginwidth=0 marginheight=0></frame> </frameset> --- hello.html hello

The black band on WinNT is fixed and the dual scroll bars on the Mac should be fixed also.

This doesn't look fixed at all on any platforms using 4/1 builds. You can look at www.stocksite.com or my test case at slip/projects/test/install/indexframe.html Your test case doesn't quite look the same as this site. Re-opening.

whoops that's http://slip/projects/dogbert/test/install/indexframe.html

I tried www.stocksite.com on the 4/1 optimized bits from mozilla.org on WinNT and the black bar to the right was gone as I reported when I closed the bug. Maybe this is now a Mac/Unix only bug (as originally reported). Reassigning to Pierre, CCing Ramiro.

I see the dual scroll bars on the NT build also. Perhaps this is a feature I'm not aware of? The ability to actually scroll the chrome? I hope not. This may not be a frames bug, actually.

Ive seen this bug only in the appruner on Linux. I think it was introduced with evaughan@netscape.com box changes. Adding evaughan@netscape.com to cc.

I can reproduce the bug on Win32 as well as on Mac with today's optimized build of AppRunner (not Viewer). Reassigned to karnaze.

This bug occurs on the apprunner on just about every url - on the apprunner only. Eric, do you have any idea if your layout box changes have anything to do with it ?

Pierre's 4/5 comments and my comments on 4/1 indicate that it works on WinNT Viewer. This sounds like an apprunner only bug. Reassigning to Eric.

Number one the crome should not be scrollable ever. We need to fix the code the creates the scrollbars to it doesn't create them. But it seems that the window is coming up smaller than what it thinks. I'll take a look when I get a working build.

I'm seeing double vertical scrollbars (one of which scrolls the chrome) at www.mozilla.org using today's optimized build on Win98. moving to m5

To clarify, i see this problem consistently on both linux and nt.

I know why this is happening. Will code a fix tomorrow.

I'm referring to the fact that the chrome scrolls. This bug seems to have mutated from a problem with some specific site's frameset to now be referring to the fact that the outermost webshell in apprunner is scrollable when it shouldn't be. I'm changing the title of the bug to reflect this.

Ok, I have a fix for this that is right for XUL. The style on the root tag is used to determine what the scrolling policy for the chrome should be. This allows XUL writers to have scrollable or non-scrollable chrome as they see fit.

This might be a good candidate to slip into M4.

*** Bug 4536 has been marked as a duplicate of this bug. ***

Fixed and checked in.

*** Bug 4150 has been marked as a duplicate of this bug. ***

verified in 4/13 builds