Bug 67827 - event.stopPropagation does not prevent click events from activating links
Summary: event.stopPropagation does not prevent click events from activating links
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-08 19:07 PDT by Marc Hoyois
Modified: 2011-09-08 22:47 PDT (History)
2 users (show)

See Also:


Attachments
HTML file demonstrating the bug (643 bytes, text/html)
2011-09-08 19:07 PDT, Marc Hoyois
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Hoyois 2011-09-08 19:07:54 PDT
Created attachment 106830 [details]
HTML file demonstrating the bug

Overview:
If a click event on a children of an <a> tag is stopped with stopPropagation(), the link is still activated. Even capturing the click event on the document before it descends to the link does not work.

Steps to reproduce:
Check the attached html page: clicking inside the video element navigates to webkit.org.

Notes:
I know event.preventDefault() can be used to neutralize links, but this is not sufficient in many use cases.
For example, in the attached HTML page, a video element sits inside a div which is inside a link. What if we want clicks on the blue div to activate the link,
but not clicks on the video? The only way to do it is to preventDefault() the click on the video element which makes the controls unusable…
Comment 1 Alexey Proskuryakov 2011-09-08 22:16:02 PDT
This is correct behavior - default handler invocation is not part of event dispatch. It always happens after event dispatch unless the event is canceled (via calling preventDefault() or returning false from a handler). Resolving as INVALID.

Why are you saying that this is a bug? Are we doing something different from other browsers?

You should be able to implement the desired behavior by not using default handling, and instead implementing navigation in JS after checking event.target. Also, you could just position the video element on top of the link without making it a child of <a>.

The situation with video is a special case. Eric told me about it some time ago, but I don't remember the details - there may be another suggestion floating around.
Comment 2 Marc Hoyois 2011-09-08 22:47:39 PDT
I figured this might be the intended behavior. Thanks for clarifying. I realize now that the real issue is that the shadow DOM is invisible in Javascript, otherwise as you say you could always achieve what you want by checking event.target. Funnily enough the shadow DOM used to be fully accessible through event properties a while ago, but I guess that was considered a bug and was fixed.