10503 - [DOGFOOD] [blocker] Overlappng views with native windows clip each other

Assignee

Description

•

26 years ago

When rendering, scrollbars substract their current region from the clip rect thus causing to "clip out" a region in higher level view. This is a blocker bug for xp menus and for the combobox. Example code: <html> <body bgcolor="#FFFFFF" text="#000000"> <form> <div id="myDiv1" style="position:absolute;z-index:1;top:10px;left:10px;background-color:gray;widt h:100px;height:75px;overflow:scroll">Hello<BR>Hello<BR>Hello<BR>Hello<BR>Hello<B R></div> <div id="myDiv2" style="position:absolute;z-index:5;top:40px;left:40px;background-color:blue;widt h:100px;height:75px;overflow:scroll">Hello<BR>Hello<BR>Hello<BR>Hello<BR>Hello<B R></div> </form> </body> </html>

David Hyatt

Comment 1

•

26 years ago

I am seeing a different bug in the XP menus that is preventing them from working. Maybe it's the same bug, but from the description, it doesn't sound like it. The bug I'm seeing is that if I have a popup view (e.g., one of my XP menus), and it pops up on top of an iframe (which has its own view), then everywhere that my popup view overlaps with the iframe's view, the contents of the iframe view are drawn in my popup view instead of my contents. My menus work fine when they don't overlap with another view, but since they tend to pop up over a content iframe, I need this to work. I'd be happy to demo the problem to you if you want to come by my cube (2nd floor b21 in the corner closest to Ellis and farthest from Middlefield).

David Hyatt

Comment 2

•

26 years ago

Ok, maybe it is the same bug. What do I know? :)

rods (gone)

Assignee

Comment 3

•

26 years ago

My description may not have been as detailed as it should have been. But from what I know and from your description they are the same bug. Basically, the clip region is set up for the very top level view, then for some reason the ViewManager lets other views "below" it muck with the clip region before the drawing is done. I think the other views are in the list of updated view because the pop view is being placed over them, so it somehow thinks they need to be included in the display list. The other strange thing is that when the display list (of views) is created, the top-level view is toward the front of the list and the scrollbar views (the guys that do the unwanted clipping) come after it. Then the list is processed front to back, just as the painting is supposedly front to back. I'll state that this is some of thee most confusing code I have yet to look at, and it has zero comments as to what is suppose to go on. The ScratchPoint is involved in this whole problem which is really just a flag for identifying a part of a view sub-tree are the root for some other view.