Ian Ian - 2 months ago 7
Javascript Question

Why doesn't click event always fire?

If you're revisiting this question I've moved all the updates to the bottom so it actually reads better as a question.

The Problem



I've got a bit of a strange problem handling browser events using
D3
. Unfortunately this sits in quite a large application, and because I'm completely lost on what the cause is I'm struggling to find a small reproduceable example so I'm going to provide as much hopefully useful information as I can.

So my problem is that
click
events don't seem to fire reliably for certain DOM Elements. I have two different sets of elements Filled circles and White circles. You can see in the screenshot below 1002 and 1003 are white circles, while Suppliers is a filled circle.

enter image description here

Now this problem only occurs for the white circles which I don't understand. The screenshot below shows what happens when I click the circles. The order of clicks is shown via the red numbers, and the logging associated with them. Essentially what you see is:


  • mousedown

  • mouseup

  • sometimes a click



The issue is a bit sporadic. I had managed to track down a realiable reproduction but after a few refreshes of the browser it's now much harder to reproduce. If I alternate click on 1002 and 1003 then I keep getting
mousedown
and
mouseup
events but never a
click
. If I click on one of them a second time then I do get a
click
event. If I keep clicking on the same one (not shown here) only every other click fires the
click
event.

If I repeat the same process with a filled circle like Suppliers then it works fine and
click
is fired every single time.




How the Circles are created



So the circles (aka Planets in my code) have been created as a modular component. There for the data is looped through and an instance for each is created

data.enter()
.append("g")
.attr("class", function (d) { return d.promoted ? "collection moon-group" : "collection planet-group"; })
.call(drag)
.attr("transform", function (d) {
var scale = d.size / 150;
return "translate(" + [d.x, d.y] + ") scale(" + [scale] + ")";
})
.each(function (d) {

// Create a new planet for each item
d.planet = new d3.landscape.Planet()
.data(d, function () { return d.id; })
.append(this, d);
});


This doesn't tell you all that much, underneath a
Force Directed
graph is being used to calculate positions. The code within the
Planet.append()
function is as follows:

d3.landscape.Planet.prototype.append = function (target) {
var self = this;

// Store the target for later
self.__container = target;
self.__events = new custom.d3.Events("planet")
.on("click", function (d) { self.__setSelection(d, !d.selected); })
.on("dblclick", function (d) { self.__setFocus(d, !d.focused); self.__setSelection(d, d.focused); });

// Add the circles
var circles = d3.select(target)
.append("circle")
.attr("data-name", function (d) { return d.name; })
.attr("class", function(d) { return d.promoted ? "moon" : "planet"; })
.attr("r", function () { return self.__animate ? 0 : self.__planetSize; })
.call(self.__events);


Here we can see the circles being appended (note each Planet is actually just a single circle). The custom.d3.Events is constructed and called for the circle that has just been added to the DOM. This code is used for both the filled and the white circles, the only difference is a slight variation in the classes. The DOM produced for each looks like:

Filled



<g class="collection planet-group" transform="translate(683.080338895066,497.948470463691) scale(0.6666666666666666,0.6666666666666666)">
<circle data-name="Suppliers" class="planet" r="150"></circle>
<text class="title" dy=".35em" style="font-size: 63.1578947368421px;">Suppliers</text>
</g>


White



<g class="collection moon-group" transform="translate(679.5720546510213,92.00957926233855) scale(0.6666666666666666,0.6666666666666666)">
<circle data-name="1002" class="moon" r="150"></circle>
<text class="title" dy=".35em" style="font-size: 75px;">1002</text>
</g>





What does custom.d3.events do?



The idea behind this is to provide a richer event system than you get by default. For example allowing double-clicks (that don't trigger single clicks) and long clicks etc.

When events is called with the
circle
container is executes the following, setting up some
raw
events using D3. These aren't the same ones that have been hooked up to in the
Planet.append()
function, because the
events
object exposes it's own custom dispatch. These are the events however that I'm using for debugging/logging;

custom.d3.Events = function () {

var dispatch = d3.dispatch("click", "dblclick", "longclick", "mousedown", "mouseup", "mouseenter", "mouseleave", "mousemove", "drag");

var events = function(g) {
container = g;

// Register the raw events required
g.on("mousedown", mousedown)
.on("mouseenter", mouseenter)
.on("mouseleave", mouseleave)
.on("click", clicked)
.on("contextmenu", contextMenu)
.on("dblclick", doubleClicked);

return events;
};

// Return the bound events
return d3.rebind(events, dispatch, "on");
}


So in here, I hook up to a few events. Looking at them in reverse order:

click



The click function is set to simply log the value that we're dealing with

function clicked(d, i) {
console.log("clicked", d3.event.srcElement);
// don't really care what comes after
}


mouseup



The mouseup function essentially logs, and clear up some global window objects, that will be discussed next.

function mouseup(d, i) {
console.log("mouseup", d3.event.srcElement);
dispose_window_events();
}


mousedown



The mousedown function is a little more complex and I'll include the entirety of it. It does a number of things:


  • Logs the mousedown to console

  • Sets up window events (wires up mousemove/mouseup on the window object) so mouseup can be fired even if the mouse is no longer within the circle that triggered mousedown

  • Finds the mouse position and calculates some thresholds

  • Sets up a timer to trigger a long click

  • Fires the mousedown dispatch that lives on the custom.d3.event object

    function mousedown(d, i) {
    console.log("mousedown", d3.event.srcElement);

    var context = this;
    dragging = true;
    mouseDown = true;

    // Wire up events on the window
    setup_window_events();

    // Record the initial position of the mouse down
    windowStartPosition = getWindowPosition();
    position = getPosition();

    // If two clicks happened far apart (but possibly quickly) then suppress the double click behaviour
    if (windowStartPosition && windowPosition) {
    var distance = mood.math.distanceBetween(windowPosition.x, windowPosition.y, windowStartPosition.x, windowStartPosition.y);
    supressDoubleClick = distance > moveThreshold;
    }
    windowPosition = windowStartPosition;

    // Set up the long press timer only if it has been subscribed to - because
    // we don't want to suppress normal clicks otherwise.
    if (events.on("longclick")) {
    longTimer = setTimeout(function () {
    longTimer = null;
    supressClick = true;
    dragging = false;
    dispatch.longclick.call(context, d, i, position);
    }, longClickTimeout);
    }

    // Trigger a mouse down event
    dispatch.mousedown.call(context, d, i);
    if(debug) { console.log(name + ": mousedown"); }
    }






Update 1

I should add that I have experienced this in Chrome, IE11 and Firefox (although this seems to be the most reliable of the browsers).

Unfortunately after some refresh and code change/revert I've struggled getting the reliable reproduction. What I have noticed however which is odd is that the following sequence can produce different results:


  • F5 Refresh the Browser

  • Click on
    1002



Sometimes this triggeres
mousedown
,
mouseup
and then
click
. Othertimes it misses off the
click
. It seems quite strange that this issue can occur sporadically between two different loads of the same page.

I should also add that I've tried the following:


  • Caused
    mousedown
    to fail and verify that
    click
    still fires, to ensure a sporadic error in
    mousedown
    could not be causing the problem. I can confirm that
    click
    will fire event if there is an error in
    mousedown
    .

  • Tried to check for timing issues. I did this by inserting a long blocking loop in
    mousedown
    and can confirm that the
    mouseup
    and
    click
    events will fire after a considerable delay. So the events do look to be executing sequentially as you'd expect.






Update 2

A quick update after @CoolBlue's comment is that adding a namespace to my event handlers doesn't seem to make any difference. The following still experiences the problem sporadically:

var events = function(g) {
container = g;

// Register the raw events required
g.on("mousedown.test", mousedown)
.on("mouseenter.test", mouseenter)
.on("mouseleave.test", mouseleave)
.on("click.test", clicked)
.on("contextmenu.test", contextMenu)
.on("dblclick.test", doubleClicked);

return events;
};


Also the
css
is something that I've not mentioned yet. The css should be similar between the two different types. The complete set is shown below, in particular the
point-events
are set to
none
just for the label in the middle of the circle. I've taken care to avoid clicking on that for some of my tests though and it doesn't seem to make much difference as far as I can tell.

/* Mixins */
/* Comment here */
.collection .planet {
fill: #8bc34a;
stroke: #ffffff;
stroke-width: 2px;
stroke-dasharray: 0;
transition: stroke-width 0.25s;
-webkit-transition: stroke-width 0.25s;
}
.collection .title {
fill: #ffffff;
text-anchor: middle;
pointer-events: none;
-webkit-touch-callout: none;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
font-weight: normal;
}
.collection.related .planet {
stroke-width: 10px;
}
.collection.focused .planet {
stroke-width: 22px;
}
.collection.selected .planet {
stroke-width: 22px;
}

.moon {
fill: #ffffff;
stroke: #8bc34a;
stroke-width: 1px;
}
.moon-container .moon {
transition: stroke-width 1s;
-webkit-transition: stroke-width 1s;
}
.moon-container .moon:hover circle {
stroke-width: 3px;
}
.moon-container text {
fill: #8bc34a;
text-anchor: middle;
}
.collection.moon-group .title {
fill: #8bc34a;
text-anchor: middle;
pointer-events: none;
font-weight: normal;
}
.collection.moon-group .moon {
stroke-width: 3px;
transition: stroke-width 0.25s;
-webkit-transition: stroke-width 0.25s;
}
.collection.moon-group.related .moon {
stroke-width: 10px;
}
.collection.moon-group.focused .moon {
stroke-width: 22px;
}
.collection.moon-group.selected .moon {
stroke-width: 22px;
}
.moon:hover {
stroke-width: 3px;
}





Update 3

So I've tried ruling different things out. One is to change the CSS such that the
white
circles 1002 and 1003 now use the same class and therefore same CSS as Suppliers which is the one that worked. You can see the image and CSS below as proof:

enter image description here

<g class="collection planet-group" transform="translate(1132.9999823040162,517.9999865702812) scale(0.6666666666666666,0.6666666666666666)">
<circle data-name="1003" class="planet" r="150"></circle>
<text class="title" dy=".35em" style="font-size: 75px;">1003</text>
</g>


I also decided to modify the
custom.d3.event
code as this is the most complex bit of eventing. I stripped it right back down to simply just logging:

var events = function(g) {
container = g;

// Register the raw events required
g.on("mousedown.test", function (d) { console.log("mousedown.test"); })
.on("click.test", function (d) { console.log("click.test"); });

return events;
};


Now it seems that this still didn't solve the problem. Below is a trace (now I'm not sure why I get two click.test events fired each time - appreciate if anyone can explain it... but for now taking that as the norm). What you can see is that on the ocassion highlighted, the
click.test
did not get logged, I had to click again - hence the double
mousedown.test
before the click was registered.

enter image description here




Update 4

So after a suggestion from @CoolBlue I tried looking into the
d3.behavior.drag
that I've got set up. I've tried removing the wireup of the drag behaviour and I can't see any issues after doing so - which could indicate a problem in there. This is designed to allow the circles to be dragged within a force directed graph. So I've added some logging in the drag so I can keep an eye on whats going on:

var drag = d3.behavior.drag()
.on("dragstart", function () { console.log("dragstart"); self.__dragstart(); })
.on("drag", function (d, x, y) { console.log("drag", d3.event.sourceEvent.x, d3.event.sourceEvent.y); self.__drag(d); })
.on("dragend", function (d) { console.log("dragend"); self.__dragend(d); });


I was also pointed to the
d3
code base for the drag event which has a
suppressClick
flag in there. So I modified this slightly to see if this was suppressing the click that I was expecting.

return function (suppressClick) {
console.log("supressClick = ", suppressClick);
w.on(name, null);
...
}


The results of this were a bit strange. I've merged all the logging together to illustrate 4 different examples:


  • Blue: The click fired correctly, I noted that
    suppressClick
    was false.

  • Red: The click didn't fire, it looks like I'd accidentally triggered a move but
    suppressClick
    was still false.

  • Yellow: The click did fire,
    suppressClick
    was still false but there was an accidental move. I don't know why this differs from the previous red one.

  • Green: I deliberately moved slightly when clicking, this set
    suppressClick
    to true and the click didn't fire.



enter image description here




Update 5

So looking in depth at the
D3
code a bit more, I really can't explain the inconsistencies that I see in the behavior that I detailed in update 4. I just tried something different on the off-chance to see if it did what I expected. Basically I'm forcing
D3
to never suppress the click. So in the drag event

return function (suppressClick) {
console.log("supressClick = ", suppressClick);
suppressClick = false;
w.on(name, null);
...
}


After doing this I still managed to get a fail, which raises questions as to whether it really is the suppressClick flag that is causing it. This might also explain the inconsistencies in the console via update #4. I also tried upping the
setTimeout(off, 0)
in there and this didn't prevent all of the clicks from firing like I'd expect.

So I believe this suggests maybe the
suppressClick
isn't actually the problem. Here's a console log as proof (and I also had a colleague double check to ensure that I'm not missing anything here):

enter image description here




Update 6

I've found another bit of code that may well be relevant to this problem (but I'm not 100% sure). Where I hook up to the
d3.behavior.drag
I use the following:

var drag = d3.behavior.drag()
.on("dragstart", function () { self.__dragstart(); })
.on("drag", function (d) { self.__drag(d); })
.on("dragend", function (d) { self.__dragend(d); });


So I've just been looking into the
self.__dragstart()
function and noticed a
d3.event.sourceEvent.stopPropagation();
. There isn't much more in these functions (generally just starting/stopping the force directed graph and updating positions of lines).

I'm wondering if this could be influencing the click behavior. If I take this
stopPropagation
out then my whole surface begins to pan, which isn't desirable so that's probably not the answer, but could be another avenue to investigate.




Update 7

One possible glaring emissions that I forgot to add to the original question. The visualization also supports zooming/panning.

self.__zoom = d3.behavior
.zoom()
.scaleExtent([minZoom, maxZoom])
.on("zoom", function () { self.__zoomed(d3.event.translate, d3.event.scale); });


Now to implement this there is actually a large rectangle over the top of everything. So my top level
svg
actually looks like:

<svg class="galaxy">
<g width="1080" height="1795">
<rect class="zoom" width="1080" height="1795" style="fill: none; pointer-events: all;"></rect>
<g class="galaxy-background" width="1080" height="1795" transform="translate(-4,21)scale(1)"></g>
<g class="galaxy-main" width="1080" height="1795" transform="translate(-4,21)scale(1)">
... all the circles are within here
</g>
</svg>


I remembered this when I turned off the
d3.event.sourceEvent.stopPropagation();
in the callback for the
drag
event on
d3.behaviour.drag
. This stopped any click events getting through to my circles which confused me somewhat, then I remembered the large rectangle when inspecting the DOM. I'm not quite sure why re-enabling the propagation prevents the click at the moment.

Ian Ian
Answer

I recently came across this again, and fortunately have managed to isolate the problem and work around it.

It was actually due to something being registered in the mousedown event, which was moving the DOM element svg:circle to the top based on a z-order. It does this by taking it out the DOM and re-inserting it at the appropriate place.

This produces something that flows like this:

  • mouseenter
  • mousedown
    • (move DOM element but keep same event wrapper)
    • mouseup

The problem is, as far as the browser is concerned the mousedown and mouseup occurred almost on different elements in the DOM, moving it has messed up the event model.

Therefore in my case I've applied a fix by firing the click event manually on mouseup if the original mousedown occured within the same element.

Comments