This playground shows that if a CSS border is applied to a canvas, then the onPointerDown events do not properly locate objects. Try clicking near the edges of the square to see that it does not register the highlight until you click closer to the center by (approximately) the width of the border applied (20px here), which does seem to be affected by zoom (that is, more zoomed out makes a larger “percentage” of the box not clickable).
While the “workaround” would be not to apply a border, that seems like a fragile breakpoint for mere CSS on the canvas element to cause such a huge issue in scene functionality.
Hey, we do assume that canvas is unchanged because checking the real DOM size will be a huge hit on performance
I would recommend not styling the canvas and instead do it on a container div
@Deltakosh Maybe I’m misunderstanding something about how the inner workings occur, but wouldn’t the engine already have to check the “real DOM size” on every window resize event (or for that matter, initially based off any explicit setting of the canvas element size itself via a width/height)? How would it be a performance hit to also account for border and padding (as I found out padding also affects it, based off the box-sizing property set on the canvas). Wouldn’t it just be calculating to some final “width” and “height” size for the canvas’s actual drawing space and then using that size until a new event triggers a resize?
we do not check on every frame (only on window resize) so if you change the canvas element styling we have no way (well except DOM observable but not working everywhere) to know it
It seems like maybe a ResizeObserver could work since it is actually attuned the box-model that CSS can affect for the canvas sizing. That is fairly well supported on devices
If one cares about Firefox for Android or IE, then possibly a fallback to a MutationObserver (which needs some effort to make it robust in tracking possible CSS changes, but with a bit of creativity for having it more specifically target things that would only trigger changing the canvas, might work for a fallback if one needed that fallback).
Yes and this is the whole point: we may not want to maintain this when it is not mandatory
I thought the point was that you said you had no way of detecting the change. Nothing was mentioned originally about not wanting to maintain a fix. So sorry if I misunderstood that. I guess from my perspective, something that is fragile enough to break major functionality with some CSS applied is worth coding to make it not break if such coding can be done. Anyway, thanks for the feedback. I just thought I would report it, since it seems like a bug to me.
no it is me, I was unclear with my support thingy 
But honestly if you want to try a PR I’ll gladly review it
I may at some point do that! I’m still learning some stuff with JS and GitHub, so I might wait until I’ve got a little more experience before attempting a PR on this.
1 Like