Last Comment Bug 224013 - DOM Event targets depends on CSS display property of elements
: DOM Event targets depends on CSS display property of elements
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: events
: Hixie (not reading bugmail)
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2003-10-28 19:02 PST by Alex Vincent [:WeirdAl]
Modified: 2003-11-12 23:02 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (3.07 KB, application/vnd.mozilla.xul+xml)
2003-10-28 19:06 PST, Alex Vincent [:WeirdAl]
no flags Details
This fixes the bug, as far as I can tell.... (1.38 KB, patch)
2003-10-29 18:34 PST, Boris Zbarsky [:bz] (still a bit busy)
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review

Description Alex Vincent [:WeirdAl] 2003-10-28 19:02:57 PST
Currently, Mozilla biases its event target based on the CSS display property.  A
block element in an XUL document will not receive a click event through
capturing unless the clicked element has a different styling.  (Not all stylings
will work.)  For instance, block > -moz-box, the block element will receive a
click event through capturing.  But the block element without any content, or
with only block content, will not receive any click events through capturing. 
Instead, the target is higher in the node tree.

Testcase coming up in a few seconds.  I don't know if this is a problem specific
to XUL only.
Comment 1 Alex Vincent [:WeirdAl] 2003-10-28 19:06:19 PST
Created attachment 134369 [details]

Steps to reproduce:
(1) Click in any of the green or blue boxes

Expected Results:   At least three capturing notices added to the textbox. 
Clicking in a green box should add five capturing notices.

Actual Results:  In some of the testcases, clicking in a green box or a blue
adds only one capturing notice, for the groupbox.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2003-10-28 21:11:51 PST
Events happening on XBL anonymous content get retargeted in all sorts of bizarre
ways when they cross the anonymous content boundary.  Are you sure that's not
what you're seeing?  Can you create a non-XBL testcase for this bug?
Comment 3 Alex Vincent [:WeirdAl] 2003-10-28 21:40:01 PST
bz: Um, the testcase uses the XBL binding only to show the XBL event listener. 
If you'll look at the source, I also do testing from JS, independent of XBL. 
The content is not inserted anonymously.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2003-10-28 21:55:53 PST
Does anything change if you attach the event listeners via attributes or DOM
instead of XBL?
Comment 5 Alex Vincent [:WeirdAl] 2003-10-29 18:00:46 PST
You mean like this, as is already in the source code?

  <script type="application/x-javascript"><![CDATA[
const textbox = document.getElementById("textbox");

function clearbox() {
  textbox.value = "";

function addXBLText(id) {
  textbox.value += "Click event captured through XBL event listener at " + id +

function addJSText(id) {
  textbox.value += "Click event captured through JS event listener at " + id + "\n";

const tester = document.getElementById("tester")

tester.addEventListener("click", function() {
}, true);

function eventJSText(evt) {

var testboxes =
document.getElementsByTagNameNS("http://localhost/namespaces/test", "*");
for (var i = 0; i < testboxes.length; i++) {
  testboxes[i].addEventListener("click", eventJSText, true);
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2003-10-29 18:25:03 PST
Ah, well.  The problem is in fact a XUL-only problem.  The issue is that
nsBoxFrame::GetFrameForPoint returns NS_ERROR_FAILURE if the layer is not

But a block with no content is not a target in the foreground layer (even if it
has a non-transparent background (see nsBlockFrame::GetFrameForPoint).
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2003-10-29 18:34:58 PST
Created attachment 134447 [details] [diff] [review]
This fixes the bug, as far as I can tell....

Not sure why this early return is even there.. the checkin comment is not
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2003-10-29 18:35:24 PST
Comment on attachment 134447 [details] [diff] [review]
This fixes the bug, as far as I can tell....

David, what do you think?
Comment 9 Alex Vincent [:WeirdAl] 2003-10-29 19:58:02 PST
One of my concerns (even before filing this bug) is what will this do to XUL
widgets with anonymous content?  Will it significantly change the DOM event
model (particularly originalTarget and target)?

This is one area I admit freely to not being that educated on.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2003-10-29 20:43:54 PST
WeirdAl, what happens when you click is that we determine which node was clicked
on.  Then we start the event there.  All this does is change the function that
determines the "clicked on" node to take into account backgrounds in XUL the way
it does in HTML and XML...
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2003-11-12 23:02:22 PST

Note You need to log in before you can comment on or make changes to this bug.