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.
Created attachment 134369 [details] 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.
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?
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?
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).
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 helpful.
Comment on attachment 134447 [details] [diff] [review] This fixes the bug, as far as I can tell.... David, what do you think?
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...