Closed
Bug 311284
Opened 19 years ago
Closed 18 years ago
nsContainerFrame considers self in the foreground layer
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: bzbarsky, Unassigned)
References
Details
nsContainerFrame::GetFrameForPoint considers self in the foreground layer. So
if you have a container frame with kids that have no foregrounds, it'll end up
getting the hit instead of the kid getting the hit. This is apparently
particularly a problem if the nsContainerFrame is a scrollframe and the kid is a
scrollcorner (which only has background, like most of XUL).
Given the way nsContainerFrame::Paint works, I think we should be passing
aWhichLayer == NS_FRAME_PAINT_LAYER_BACKGROUND for aConsiderSelf when we call
GetFrameForPointUsing.
Comment 1•19 years ago
|
||
(In reply to comment #0)
>This is apparently particularly a problem if the nsContainerFrame is a
>scrollframe and the kid is a scrollcorner
Most visibly, cursor styles on the scrollcorner have no effect.
This isn't necessarily a bug in nsContainerFrame -- if we pick one, we need to
override GetFrameForPoint and Paint in the subclasses for which that choice is
wrong, which I think we mostly do. (We want inlines to consider themselves in
the foreground layer, and blocks in the background.) Alternatively, we could
add a virtual function to nsContainerFrame called GetSelfLayer and override its
default implementation in all of those classes that use nsContainerFrame's Paint
or GetFrameForPoint and for which that default implementation is wrong.
(And it's worth working out whether XUL boxes are block or inline for this
purpose, and perhaps doing layer transitioning (i.e., ignore two layers, and map
the third to all three) at some points. Never mind that we probably need some
paint layer work for inline-block, etc.)
I need to rework the paint system anyway.
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.9a2?
Reporter | ||
Comment 5•18 years ago
|
||
So roc reworked the paint system, and I made the mistake of not posting a testcase here. Neil, do you happen to know whether the scrollcorner problem is still there?
Keywords: qawanted
Whiteboard: [Is this still an issue on trunk?]
Comment 6•18 years ago
|
||
(In reply to comment #5)
>Neil, do you happen to know whether the scrollcorner problem is still there?
Comparing to branch, textarea scrollcorner cursors are now correct.
Reporter | ||
Comment 7•18 years ago
|
||
Yeah, code inspection also suggests bug 317375 fixed this. Excellent.
Updated•6 years ago
|
Product: Core → Core Graveyard
Assignee | ||
Updated•6 years ago
|
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•