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.

(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.

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?

(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.

Yeah, code inspection also suggests bug 317375 fixed this. Excellent.