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

Status: VERIFIED FIXED

(Core :: DOM: Events, defect, P2)

Description

[Joe Hewitt]

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.

Comment 1

[Joe Hewitt]

Attachment: see the bug in action

Comment 2

[Johnny Stenback (:jst)]

DOM Event targetting problem, over to joki.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Confirming bug, since I know its there.  

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Taking this bug, since I should have a chance to fix it in the beta3 timeframe.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Nisheeth Ranjan]

Marking nsbeta3-.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Future.

Comment 9

[Jano]

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>

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: my mostly working (except scrollbars) attempt to check clip on the view to which the event was sent by the viewmanager

Comment 14

[Kevin McCluskey (gone)]

*** Bug 61470 has been marked as a duplicate of this bug. ***

Comment 15

[Kevin McCluskey (gone)]

*** Bug 48611 has been marked as a duplicate of this bug. ***

Comment 16

[Vladimir Ermakov]

QA Contact Update

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 79134 has been marked as a duplicate of this bug. ***

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 90861 has been marked as a duplicate of this bug. ***

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 98005 has been marked as a duplicate of this bug. ***

Comment 20

[Fabian Guisset]

Is there any chance dbaron's patch can be further polished? 5 dups already...

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 106512 has been marked as a duplicate of this bug. ***

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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...

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Maybe (joki or dbaron) and attinasi would like to check this?

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

r=dbaron

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 124803 has been marked as a duplicate of this bug. ***

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Let's get some traction on this bug. Stealing, and requesting sr from attinasi.
The patch is still good.

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

REALLY stealing

Comment 32

[Marc Attinasi]

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

sr=attinasi

Comment 33

[Asa Dotzler [:asa]]

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

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked into trunk.

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Marking fixed

Comment 36

[Vladimir Ermakov]

verifying on build 2002-03-13-03-trunk win 98 and build 2002-03-13-09-trunk linux 

Comment 37

[Boris Zbarsky [:bzbarsky]]

*** Bug 135959 has been marked as a duplicate of this bug. ***

Comment 38

[Todd A. Fisher]

If this is working can someone update
http://www.mozilla.org/docs/dom/mozilla/bug-events.html