DOM Event targets depends on CSS display property of elements




15 years ago
15 years ago


(Reporter: WeirdAl, Unassigned)




Firefox Tracking Flags

(Not tracked)



(2 attachments)



15 years ago
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

15 years ago
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.
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

15 years ago
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.
Does anything change if you attach the event listeners via attributes or DOM
instead of XBL?

Comment 5

15 years ago
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);
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).
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 on attachment 134447 [details] [diff] [review]
This fixes the bug, as far as I can tell....

David, what do you think?
Attachment #134447 - Flags: superreview?(dbaron)
Attachment #134447 - Flags: review?(dbaron)

Comment 9

15 years ago
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.
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...
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.