The default bug view has changed. See this FAQ.

[EVENTTARG]mouse events don't pass through clipped element

VERIFIED FIXED in mozilla1.0

Status

()

Core
DOM: Events
P2
normal
VERIFIED FIXED
17 years ago
11 years ago

People

(Reporter: Joe Hewitt, Assigned: roc)

Tracking

({dom2, polish})

Trunk
mozilla1.0
dom2, polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
The problem occurs under these circumstances: when an absolutely positioned, 
clipped element overlaps another element, but because of clipping, the element 
underneath shows through.  In this case, mouse events do not pass through the 
clipped element to the element below.  In the example I am about to upload, you 
will see that it is not possible to interact with a button even though you can 
see it.

I am not sure if this is a bug, or the desired behavior.  I can say that it is 
certainly a behavior which I wish were different.  Under IE5, it is possible to 
click the button in the example I'm giving (although the example doesn't work 
in IE5 because IE5 interprets clip rects different).  

The DOM Event spec doesn't talk about what to do in this situation, so it's 
pretty much up for interpretation. There are probably cases where you would 
actually want to be able to overlay an invisible element which would steal all 
mouse events... although this effect would be better to do with event capture.  
With that in mind, I think it's probably better to let the events go through.
(Reporter)

Comment 1

17 years ago
Created attachment 7406 [details]
see the bug in action
DOM Event targetting problem, over to joki.
Assignee: jst → joki
Confirming bug, since I know its there.  
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: mouse events don't pass through clipped element → [EVENTTARG]mouse events don't pass through clipped element

Updated

17 years ago
Status: NEW → ASSIGNED
Taking this bug, since I should have a chance to fix it in the beta3 timeframe.
Assignee: joki → dbaron
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Nominating nsbeta3 - this is a serious problem.  When authors use the clip
property, the user will be unable to click on links that are visible.  This is
disconcerting to the user and can make the page unusable on Mozilla.  It's also
wrong, not by any spec, but by the de facto spec that controls how we decide
which frame gets events.
Keywords: correctness, nsbeta3, polish
Giving back to joki since I was too lazy to fix it while he was away.  It's
probably easy to fix for the most common cases, but a good bit harder to fix
completely.
Assignee: dbaron → joki
Status: ASSIGNED → NEW

Comment 7

17 years ago
Marking nsbeta3-.
Whiteboard: [nsbeta3-]
Future.
Target Milestone: --- → Future

Comment 9

16 years ago
The clipped region catches the events. 

Try this :

<div id="clipped" style="position:absolute;top:0;clip:rect(0,200,40,0); 
background-color:yellow;"
onmouseover="alert('i_m_a_clipped_div')">
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<br>
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb<br>
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccc<br>
</div>
Code where clipping is handled in layout:
http://lxr.mozilla.org/seamonkey/ident?i=SetClipRect
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsContainerFrame.cpp#576
Keywords: dom2
Component: DOM Level 2 → DOM Events
One interesting thing that seems to be happening here is that when we have a
view for an element with |clip|, the view is created with too large a size --
ignoring the clip.  I would think it ought to be created at the size of the
clip, since that would allow the view manager to optimize things better.  If
this didn't happen, the view system would, I think, handle that case.  (See
the attached testcase above -- the bounds for the view are
{120,120,2400,2400}.)

However, layout would still need to handle all the cases of elements without
views.
I'm having trouble figuring out where the code is that implements the 'clip'
property.  It doesn't seem to be done through the view system, since the clip on
the views is not set correctly (even though it probably should be).

I did mess around with view system stuff... I think there may be a bug where
we're sending events to views that have the event's region clipped out if that
view has a widget / is a toplevel view... but could that ever happen?  My patch
to try and fix it messed up scrollbars a bit, but otherwise worked.  (I'll
attach it...)
Created attachment 26735 [details] [diff] [review]
my mostly working (except scrollbars) attempt to check clip on the view to which the event was sent by the viewmanager
*** Bug 61470 has been marked as a duplicate of this bug. ***
*** Bug 48611 has been marked as a duplicate of this bug. ***

Comment 16

16 years ago
QA Contact Update
QA Contact: vidur → vladimire
*** Bug 79134 has been marked as a duplicate of this bug. ***
Depends on: 87839
No longer depends on: 87839
Depends on: 87839
*** Bug 90861 has been marked as a duplicate of this bug. ***
*** Bug 98005 has been marked as a duplicate of this bug. ***

Comment 20

16 years ago
Is there any chance dbaron's patch can be further polished? 5 dups already...
*** Bug 106512 has been marked as a duplicate of this bug. ***
Changing the view bounds to match the clip rect is not the right way to go. What
if we later extend clipping to support general regions? Instead we should just
fix event handling and painting to use the clip information.
Actually this really needs to be fixed in Layout and here's why: the clip rect
you set on a view only applies to its child views (I think this is so that
"overflow: hidden" can still paint its borders and background). So layout needs
to check to see if each event is in the frame's clip rect, and if not, return
"not handled" to the view manager.
Created attachment 60603 [details] [diff] [review]
Make PresShell check to see if an event falls in the clip region

This patch fixes the testcase. I'm pretty sure it's the right thing to do. As I
just explained, the view manager can't do this. Let's get reviews for this
patch and close this bug out...
Maybe (joki or dbaron) and attinasi would like to check this?
Seems fine to me, although it adds yet another thing in layout that depends on
all absolutely positioned frames (even those with 'z-index: auto', which would
have been nice not to have to hack into the view manager) having views.  I don't
feel qualified to review the bit in HandleEvent without looking into that code a
bit more, though.
> Seems fine to me, although it adds yet another thing in layout that depends
> on all absolutely positioned frames (even those with 'z-index: auto', which
> would have been nice not to have to hack into the view manager) having views.

Are you suggesting that if absolutely positioned frames didn't have to have
views, then we wouldn't have to implement z-index: auto in the view manager?
That is far from true. There are other reasons why we need to create a view for
a frame (for example, a "position: fixed" frame with a widget), and as long as
those reasons apply to any frame which might have "z-index: auto", the view
manager needs to understand "z-index: auto".

Furthermore I think it's great that z-index is entirely taken care of in the
view manager; I wish other stuff that is essentially replicated in the view
manager and in layout could be moved solely into one or the other, preferably
the view manager because it's small and manageable unlike layout :-). So the
more views, the better :-).
Comment on attachment 60603 [details] [diff] [review]
Make PresShell check to see if an event falls in the clip region

r=dbaron
Attachment #60603 - Flags: review+
*** Bug 124803 has been marked as a duplicate of this bug. ***
Let's get some traction on this bug. Stealing, and requesting sr from attinasi.
The patch is still good.
OS: Windows 98 → All
Priority: P3 → P2
Hardware: PC → All
Target Milestone: Future → mozilla1.0
Attachment #26735 - Attachment is obsolete: true
REALLY stealing
Assignee: joki → roc+moz

Comment 32

15 years ago
Comment on attachment 60603 [details] [diff] [review]
Make PresShell check to see if an event falls in the clip region

sr=attinasi
Attachment #60603 - Flags: superreview+

Comment 33

15 years ago
Comment on attachment 60603 [details] [diff] [review]
Make PresShell check to see if an event falls in the clip region

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #60603 - Flags: approval+
Fix checked into trunk.
Marking fixed
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 36

15 years ago
verifying on build 2002-03-13-03-trunk win 98 and build 2002-03-13-09-trunk linux 
Status: RESOLVED → VERIFIED
*** Bug 135959 has been marked as a duplicate of this bug. ***

Comment 38

11 years ago
If this is working can someone update
http://www.mozilla.org/docs/dom/mozilla/bug-events.html
You need to log in before you can comment on or make changes to this bug.