Pixi.js: Click in HTML can't be stopped from being triggered in PIXI

[georgiee]

See here:
http://jsfiddle.net/georgie/gnka1jne/

1. Click on the red rect, this will trigger an expected event 'html triggered'
2. But the yellow rect located in pixi triggers itself an event and there is no way to stop the event from outside of pixi.

Pixi registers an event listener on window at the capture phase, that's the earliest possible position where a mouse event can be listened to, isn't it ? So there can't be a solution in HTML to stop an event from being triggered in pixi ?

This might be the same?
https://github.com/GoodBoyDigital/pixi.js/issues/1725

Thanks!

[georgiee]

Here are two other problems with interaction. This seems to be a mix of a regression with 3.0.3 (following @LuQano's description that it was working before) and a normal bug in V3.

Here is my second testcase:
http://jsfiddle.net/georgie/zqzbnmf4/

Two problems:

1. Clicking is not blocked, so that an underlying element gets triggered, even if an object on top already consumed the click. It's shouldn't be necessary to stop the propagation manually as this is a behaviour someone would expect I guess?
2. Click and drag on top of another target. You will trigger a mouseup on that target which wasn't under the mouse during initiation.

Reproducing:

1. Click on the rect in the middle (which is a small zone where both larger rects are overlapping) You get two outputs. One from each rectangle.
2. Click on the yellow rect, hold and go down to the blueish one. Release. You will get the message pixi 2 triggered. Which was dispatched from the blueish rect. This is not a correct mouseup behaviour.

Related:
https://github.com/GoodBoyDigital/pixi.js/issues/1765

[englercj]

@GoodBoyDigital Can you comment on why capture phase is being used?

[jwdunn1]

I'm not convinced this is a bug. The "new and improved" default behavior makes sense if you want to grab a stack of interactive elements and move them around together. To make my app work in the same manner as it did in v3.0.2, I simply added event.stopPropagation(); to the mousedown and touchstart event handlers. So, now the top object in the stack is the only one that handles the event. You can do that in your test case also.

[georgiee]

Well, this blocking behavior is learned by most developers. Totally learned. At least by the pixi community, by all the people who are coming from AS3 and all the JS DOM guys. So why doing something differently? If you really want to drag a bunch of objects use a function to find those objects.

It's not reasonable to keep this behavior. I believe there are many good reasons why most environments are acting like this.

[krzysztof-o]

I agree with @georgiee.

[englercj]

Yeah HTML on top of the canvas should totally block interactions, the interaction manager should mimic the DOM internally wherever possible because it is what most people are familiar with.

[endel]

Hey guys,

I've made a pull-request for this https://github.com/GoodBoyDigital/pixi.js/pull/1902

Live example with the patch: http://jsfiddle.net/xnmy239h/2/

[sergebat]

II'm looking to try and rewrite the Interaction Manager in the coming weeks. Stay tuned.

Just want to chime in and ask, if there are any plans on this thread?

For example, is there a chance that Interaction Manager can be configured to use capture or bubble phase, depending on application needs? I think it should solve the topic starter problem?

I'm handling touch event globally (on parent DIV level to detect touches anywhere on the screen in one-finger arcade game), and was hoping I can do "stopPropagation" in PIXI canvas when UI is clicked).

However, as event capturing is hardcoded in PIXI, I have to make it in a bit more hacky way. edit: I realized that in my case this is not a showstopper. I can still listen for the event in bubbling phase at container level. Still it would be good to understand, why events are hardcoded to be handled at "capturing" phase.

[twhitbeck]

@englercj @GoodBoyDigital if there's no good reason to use capture phase, can we please switch to using bubble phase? I think we can all agree it's leading to confusing behavior. I'll gladly submit a PR

[davearel]

+1 on this, it's an issue for me

[endel]

Hey guys, my jsfiddle had stopped working due to the pixi.js build I had linked. Now I'm using cdnjs for v3.0.7 - which is the version I was testing on that patch - http://jsfiddle.net/xnmy239h/2/

[danwad]

Yeah HTML on top of the canvas should totally block interactions

Does anyone have a not-too-hacky workaround for this? I have DOM elements overlapping the canvas, when the mouse is over the DOM elements, I want to prevent pixi from triggering mouseover on my interactive DisplayObjects.

[jwdunn1]

I set CSS {pointer-events: none;} for the main area and {pointer-events: auto;} for the overlapping DOM elements.

[danwad]

Thanks, but this doesn't work for mouseover and mouseout because pixi uses a mousemove listener on window.document.

[Tumetsu]

I'm having the same issue as danwad. I have a DOM overlay and Pixi display object which reacts to mouseover and mouseout because of a fore mentioned reasons. Any workarounds to prevent the "hover" events like this from happening? Clicks are already working fine.

[themoonrat]

This PR: https://github.com/pixijs/pixi.js/pull/2917 will solve this problem. Patch it into your own build of PIXI for now :)

[Tumetsu]

Thanks! That did the trick for now :)

[themoonrat]

@englercj - I believe this can be closed after merging https://github.com/pixijs/pixi.js/pull/2996

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.