224013 - DOM Event targets depends on CSS display property of elements

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Alex Vincent [:WeirdAl]]

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

Attachment: testcase

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 [:bzbarsky]]

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

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 [:bzbarsky]]

Does anything change if you attach the event listeners via attributes or DOM
instead of XBL?

Comment 5

[Alex Vincent [:WeirdAl]]

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 +
"\n";
}

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

const tester = document.getElementById("tester")

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

function eventJSText(evt) {
  addJSText(evt.currentTarget.localName);
}

var testboxes =
document.getElementsByTagNameNS("http://localhost/namespaces/test", "*");
for (var i = 0; i < testboxes.length; i++) {
  testboxes[i].addEventListener("click", eventJSText, true);
}
  ]]></script>

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

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 [:bzbarsky]]

Attachment: This fixes the bug, as far as I can tell....

Not sure why this early return is even there.. the checkin comment is not
helpful.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

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 [:bzbarsky]]

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 [:bzbarsky]]

Fixed.