Ok, i havn't slept tonight so i might see a vision. When looking at comment 285 bug 68136 there grey box with a native scrollbar in it. This is on a Win98SE build from maybe a week ago I have no idea where this bug belongs, but i figured at least someone on layout can see what code creates the frame/does the painting...

wfm with a current CVS build ? Do you have a screenshot ?

I see it too with 2002022003 on w98. Screenshot coming...

yes, that is exactly what i got here too (still rebuilding a clobber here, so i couldn't make a screenshot)

I see the gray scrollable box also. I'm using Win95 with the 0.9.8 release (2002020406).

Changing QA contact

I think it appears on many (most? all?) bugzilla pages, but it's only visible on once that are really long. Another example is http://bugzilla.mozilla.org/show_bug.cgi?id=40867#c277 But i have seen the familiar "jumping scrollbar" even when loading shorter bugzilla pages where i couldn't see the box so i think that it's there, it's just that i couldn't scroll down to it

The scrollbox is a mirror of the CC listbox, over to formcontrols.

Scroll down to the bottom of the testcase and scroll slowly up, you should run in to the scrollbox pretty fast. The scrollbox is a mirror of the listbox at the top of the page. It has the same size and shape as the listbox, and if you scroll one the other scrolls too. This seems to appear on all bugzilla pages, but can be quite hard to spot since most pages are too short to show the mirror

Seeing this on Linux too. the testcase shows that this happens as soon as the page is a bit over 65500 pixels tall. Seems a lot like bug 115526 to me.

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

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

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

Another good test case: Load <http://www.xopus.org/index.jsp?menu=mozce> Control- (command-) click the link "plans to incorporate" in the second paragraph to open it in a new tab. Go to that tab, and you'll see the gray box of doom (on Mac, at least).

I have just filed bug 164625 which addresses a similar, but I think different, problem. I think bug 164625 is caused by 16-bit overflow in the native regions used by nsViewManager. That happens with pages a little of 2K pixels high, because the view manager is working in twips space (16 twips or so per pixel). That bug is fairly easy to fix by switching to our nsRegion region implementation inside the view manager. This bug is presumably caused by 16-bit pixel coordinates in GTK itself. This is much harder to fix (*cough* need XBL Form Controls *cough*).

Also if I understand Windows correctly, this bug should NOT happen in any NT-based system (NT4, 2000, XP), because NT's GDI and USER use 32-bit coordinates.

Also, blizzard says GTK2 uses 32bit coordinates, so we shouldn't see this there either.

Dup of bug 51385.

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

Changing summary to reflect the real problem. I think this could actually be solved by adding a set of checks which would hide native widgets for views which have been completely scrolled out of sight. Thus even when the 16-bit coordinates for those widgets wrap, they wouldn't interfere with the display. I'll take this bug.

actually, bug 132448 was not repeating at 2^16 pixels, but ~3200. However, bug 159556 (misduped against bug 132448 by my evil twin) is a dupe here. isn't this GFX Compositor?

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

You're right about the duplicates, but I don't really care, the important thing is that this bug is the remaining issue. I'll call this a views bug.

Here's my fix. I decided we should do it platform by platform because that's where the problem lies; some platforms don't need this at all. My fix for GTK basically hides any widget that gets moved or scrolled out of its parent's bounds. It works. This fix should be ported to Mac and Windows, at least.

CCing blizzard for review.

Hmm, this patch appears to cause popups to fail sometimes. But not always repeatably.

This fixes a bug I had with top-level windows not being shown properly. We should always show top-level windows without any special handling because they're not contained by their parents.

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

Comment on attachment 100065 [details] [diff] [review] better fix for GTK r=blizzard

Comment on attachment 100065 [details] [diff] [review] better fix for GTK Hey blizzard, you already reviewed this patch, care to add your sr stamp too? Ta.

Comment on attachment 100065 [details] [diff] [review] better fix for GTK sr=blizzard

WFM in 1/08/03 Trunk, Win XP and 1/07/03 Trunk Mac OSX.

bug still exists with linux trunk 20030109 roc: is this patch now ready to get checked in?

Yes it is. I'll check it in.

I've checked in the fix for GTK1. I'm not sure what the status is for other platforms. I would expect this to work on NT and the Mac (and according to Blizzard, GTK2). It probably doesn't work on Win9x but do we care? If not, I'll close the bug.

Bug still shows on Mac OS X (macho). taking for Mac fix.

This bug still occurs on Win98 which i think is a farily well-used platform still.

"It probably doesn't work on Win9x but do we care?"

Gtk2 should be 32bit clean.

FYI, Win98 still has more users than any other version

Someone could port the technique I used here to Win9x. Not me, since I don't have a Windows development environment anymore. Plus it would have to be tested on Win9x, obviously.

(In reply to comment #37) > I've checked in the fix for GTK1. I'm not sure what the status is for other > platforms. I would expect this to work on NT and the Mac (and according to > Blizzard, GTK2). It probably doesn't work on Win9x but do we care? If not, I'll > close the bug. > > Roc, this bug was only kept open to port your previous patch to Win98, but on the trunk now we've dropped support for that OS. So can we close this bug as FIXED?

ok