Last Comment Bug 224013 - DOM Event targets depends on CSS display property of elements
: DOM Event targets depends on CSS display property of elements
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: events
: Hixie (not reading bugmail)
Mentors:
Depends on:
Blocks:
  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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
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]
dbaron: review+
dbaron: superreview+
Details | Diff | 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]
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 [:bz] 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] 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 +
"\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 [:bz] 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
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 [:bz] 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
helpful.
Comment 8 Boris Zbarsky [:bz] 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] 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] 2003-11-12 23:02:22 PST
Fixed.

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