bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Can't mouse though images (nsStackFrame::GetFrameForPoint not implemented)

RESOLVED FIXED in mozilla1.8alpha1



14 years ago
10 years ago


(Reporter: neil@parkwaycc.co.uk, Assigned: dbaron)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [patch])


(2 attachments)



14 years ago
Steps to reproduce problem:
1. Load test case
2. Try to hover over the upper sets of squares
3. Try to hover over the lower sets of squares

The difference between the two examples is the use of box instead of image.
I used EditorFormatToolbar.css as a convenient source of hover styles.

Comment 1

14 years ago
Created attachment 146762 [details]
Test case
I'm a little confused here.  What is the expected behavior?  Why?  A _simple_
testcase would have helped.

Comment 3

14 years ago
Well the expected behaviour is that the hover effect works on both sets of
boxes. Also there are a number of ways of achieving an image underlay/overlay
and I wanted to demonstrate that all of them block hover.
So is the image below the box that should be getting hover in every single one
of those testcases?  Note that width="0" height="0" is ignored since stacks
stretch all kids out to the size of the stack.  If no order is specified does a
stack stack its kids in document order top to bottom or bottom to top?

Comment 5

14 years ago
nsStackFrame needs to override GetFrameForPoint in a useful way.
Oh, it doesn't?  I was going to look for bugs in its override after figuring out
what the behavior _should_ be, but I guess that's sorta moot... ;)
Assignee: events → nobody
Component: Event Handling → XP Toolkit/Widgets: XUL
QA Contact: ian
Summary: Can't mouse though images → Can't mouse though images (nsStackFrame::GetFrameForPoint not implemented)

Comment 7

14 years ago
GetFrameForPoint should do whatever paint does. :-)
Yeah.. paint...

nsStackFrame does not implement Paint(), so it inherits it from nsBoxFrame.

It _does_ override PaintChildren -- to only call through to
nsBoxFrame::PaintChildren if the layer is NS_FRAME_PAINT_LAYER_BACKGROUND.

Then in PaintChild() (which it also overrides) it totally ignores aWhichLayer
and paints the background, then the foreground for the child.

So logically, the thing to do for GetFrameForPoint would be to return nothing in
the foreground and walk the kids in reverse order for background, asking for
points in both layers (sorta what nsStackFrame::GetStackedFrameForPoint tries to
do... except no one calls it).


14 years ago
Assignee: nobody → dbaron

Comment 9

14 years ago
Created attachment 146794 [details] [diff] [review]

This splits out a separate child method from nsBoxFrame::GetFrameForPoint and
overrides both in nsStackFrame (although the outer only for performance).


14 years ago
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8alpha


14 years ago
Attachment #146794 - Flags: superreview?(bzbarsky)
Attachment #146794 - Flags: review?(bzbarsky)
Comment on attachment 146794 [details] [diff] [review]

>Index: nsBoxFrame.cpp
>+nsBoxFrame::GetFrameForPointChild(nsIPresContext*   aPresContext,

>+      // if the kid had a child before see if this child has mouse
>+      // though. 

I realize you just copied this, but what it should probably say instead is:

"If we had a lower frame for this point, check whether hit's box has mouse
through.  If so, stick with the lower frame that we found"

or something along those lines...

r+sr=bzbarsky with that.
Attachment #146794 - Flags: superreview?(bzbarsky)
Attachment #146794 - Flags: superreview+
Attachment #146794 - Flags: review?(bzbarsky)
Attachment #146794 - Flags: review+

Comment 11

14 years ago
(In reply to comment #10)
> I realize you just copied this, but what it should probably say instead is:

moved, not copied :-)

Comment 12

14 years ago
Fix checked in to trunk, 2004-04-22 11:59 -0700.
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 13

14 years ago
Comment on attachment 146794 [details] [diff] [review]

There's been a request that this go on the 1.7 branch, and it should be
reasonably safe.  There is a chance of regressions, but they seem like the kind
of things that would be noticed reasonably quickly, and it also seems more
likely to fix something obscure than to break it.
Attachment #146794 - Flags: approval1.7?

Comment 14

14 years ago
Comment on attachment 146794 [details] [diff] [review]

a=chofmann for 1.7
Attachment #146794 - Flags: approval1.7? → approval1.7+

Comment 15

14 years ago
Fix checked in to MOZILLA_1_7_BRANCH, 2004-04-26 16:17 -0700.
Keywords: fixed1.7


10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.