PlayCanvas intercepts all mouse events on window (breaks HTML UI) about engine HOT 5 CLOSED

UI libraries are not affected anyhow by PlayCanvas, except the fact that mouse input will propagate.
That means if your game does not care about events on canvas itself, then it just uses UI events as it used to.
But if you do care about custom input to canvas as well as UI above it, and you have a mixture of different behaviours, like in here for example: http://apps.playcanvas.com/max/tanky/colorTanks
Where you want mouse to be working in game when you still hovering minimap. And UI buttons still work.

That means it is up to a developer to define the logic of mouse interactions, and go from there.

In order to make all (dynamic selector) buttons in bootstrap to ignore mouse events, which is "logic" and not "workaround":

$('body').on('mousedown mousemove mouseup', '.btn', function(evt) {
    evt.stopPropagation();
});

It is up to your UI logic to do things, if you want to draw DOM image on top of canvas, or use div with text on top of 3D object using DOM, you might want to still have mouse events working as expected on canvas, ignoring div element above.
Or you might have custom behaviour by adding events as described above.

It is hard to find generic use case for such things as Keyboard and Mouse inputs in order to prevent most issues related to JS fragmentation on different platforms as well as allowing developers to define behaviour the way they want.

If we would provide UI framework, those things would be a part of API it self, but unfortunately we don't have any UI framework atm.

from engine.

The reason why mouse events are handled on Window: we need to handle scenarios when mouse leaves canvas bounds (for example when mouse is down and leaves canvas element), and to have mouse movement when there are elements above canvas and below mouse if developer wants it. Previously there was no option for such.

This gives possibility to have UI elements on top of canvas that have only visual purpose and it is up to developer to stop propagation of mouse events on hovering if dev wants so, or leave as it is.

In order to stop propagation you can easily follow this flow:

uiElement.addEventListener('mousedown', function(evt) {
    evt.stopPropagation();
});

Here is example where moving mouse above UI does not breaks game, especially notice it at bottom logo - game still playable.

This change were made to let developer have both options.

from engine.

The fix makes sense, but there are still a few issues. Most UI I imagine will likely be done in jQuery and other libraries (we are using bootstrap for some elements). It makes it a little bit difficult to have normal UI libraries work correctly.

The workaround on my end is to do something like this:

$('body > *:not(canvas)').on("mousedown mouseup mousemove mousewheel DOMMouseScroll", function(event) {
    event.stopPropagation();
});

This relies on the canvas always being a direct child of body - is that a valid assumption? Otherwise I'll have to likely make some kind of base css class that all UI elements include.

from engine.

That makes sense. I guess the only other way something like this could work is if UI developers had to manually send the mouse event to the canvas if they wanted pass-through instead of having the developer turn off propagation. It feels like more UI is likely to not want the event to propagate (especially because it will not propagate to the canvas by default in this way), but that is really just my opinion.

I would only recommend adding this to the documentation somewhere because it feels like other devs will probably run into this issue if they are building the UI in HTML.

from engine.

It is a valid point. Developer will have to know the way of achieving "transparent/non-transparent" elements in any case, so knowledge of stopPropagation or some other potential functionality to enforce propagation is necessary (unfortunately only "hacky" solutions come to my head for thing like that).

We will add to API reference for Mouse Input, stating clearly that Mouse events will fire as far as mouse position is within canvas bounds regardless of elements overlapping, unless the overlapped element caches the events and stops its propagation.

from engine.