Babylon forcing non-passive events?

Bugs
1

what is the point of explicitly setting passive to false if its supported?

this code path is triggered when camera attachControl is executed
and explicitly setting it was done via PR https://github.com/BabylonJS/Babylon.js/pull/9777),
but that only suppressed chrome warning for a few months, but warning is back in recent versions of chrome

src/DeviceInput/InputDevices/webDeviceInputSystem.ts:

this._elementToAttachTo.addEventListener(this._wheelEventName, this._pointerWheelEvent, passiveSupported ? { passive: false } : false);

and yes, it results in a chrome warning:

[Violation] Added non-passive event listener to a scroll-blocking 'wheel' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952
2

I submitted that PR. Per the notes there, I debated if passive should be true or false. I elected to go with false because that seemed like the safer default corresponding to how things probably worked before the PR. (It’s hard to be sure though.)

  • What version of Babylon are you using?
  • What version of Chrome are you using?

I wanted to see if I could easily replicate that original warning, and surprisingly I can not. Nor do I see it in the playground when selecting 4.x versions (and I believe I did previously.) So my assumption is that chrome has changed and no longer shows the warning. So I’m especially curious about your statement:

If anyone else wants to go down this rabbit hole…

Note that input systems related code structure changed from 4.x to 5.x . The relevant code is now here:

I came up with two PGs to make it easier to experiment (though kind-of hacky):

The second PG allows playing with noPreventDefault and the passive setting. Or at least, that was my intent. I can’t replicate the original warning though, so either Chrome has changed or I’m missing something.

Per that 2nd PG, setting noPreventDefault=false and passive=true results in warnings, as expected.

I agree that maybe Babylon should set passive=true when it can, because I think that would only ever help with performance. However, it could only do so when noPreventDefault is true.

1 Like
3

Yes, handling of this warning is really browser and version specific and there is no defacto standard.

Note that having configurable variable in a PG can lead to incorrect result as running a PG does not do a full refresh of a page in browser, so some warnings (ones that browser issues once per load) will be skipped regardless if you change a variable or not (as they are only shown when PG is first loaded). Nor will you see the warning if you open inspector after page has loaded - to reproduce, inspector must be open and then do a page refresh.

Anyhow, I’m using latest BabylonJS 5.0.0-rc.2 and I’ve tested with:

  • Edge 99 (Stable, Chromium based)
  • Edge 100 (Canary, Chromium based)
  • Chrome 99 (Stable)
  • Chrome 100 (Beta)
  • Chrome 101 (Canary)
  • Firefox 98 (Stable)

And they have different behaviors: Chrome and Edge 99 report warnings, but none of the higher versions do.

Btw, older versions of Chrome also generates same warning because of touchstart event.

[Violation] Added non-passive event listener to a scroll-blocking ‘touchstart’ event. Consider marking event handler as ‘passive’ to make the page more responsive. See Chrome Platform Status

And Firefox doesn’t care about passive events or not at all, but it reports a different warning altogether:

WEBGL_debug_renderer_info is deprecated in Firefox and will be removed. Please use RENDERER.

Anyhow…

I agree that maybe Babylon should set passive=true when it can, because I think that would only ever help with performance. However, it could only do so when noPreventDefault is true.

I agree.

4

Thanks for the note. I created a simpler PG that I believe should replicate the setup prior to that PR and so trigger that original warning:

Opening this PG, in incognito mode, with dev console open, I still don’t see those warnings. Do you? How/where are you reproducing the warnings?

How are you testing this? Fwiw, I have been running Chrome Version 99.0.4844.51 on Windows 10, and Edge 99.0.1150.36.

At this point though, I am only curious. The decision to switch to passive=true is up to Babylon.js devs. I think it would be low risk to do so? However, if deemed a risk, then I guess it could also be handled as another option. But per my original notes, I don’t see any clean way of doing that.

5
  1. with edge/chromium 99.0.1150.39 on windows 11
  2. click on your PG link
  3. open inspector
  4. click refresh in browser

he decision to switch to passive=true is up to Babylon.js devs. I think it would be low risk to do so? However, if deemed a risk, then I guess it could also be handled as another option. But per my original notes, I don’t see any clean way of doing that.

{ passive: true } should not be used only if handler calls preventDefault

and looking at actual handler method, it doesn’t: https://github.com/BabylonJS/Babylon.js/blob/7a4b9d1714225b625a797a0d1e9cfa3dc94af3d6/src/DeviceInput/InputDevices/webDeviceInputSystem.ts#L663

so its safe.

1 Like