IE11 navigator.getGamepads - Babylonjs no longer working in IE11

Bugs
1

Reposting bug report from github: 10007

navigator.getGamepads is undefined in IE11, which stops the engine from working.

Setting that to just return an empty array then leads to issues with wheel events, with the error “Unable to find input 7 for device Mouse in slot 0” issued on every scroll event. This means wheel events aren’t working at all for IE11.

I briefly looked at the code but couldn’t see anything obvious as to why that is happening.

I am however unsure as to why getGamepads is called so often.
It’s called in DeviceInputSystem._updateDevice
which has the comment that the function updates devices every frame.

This however isn’t the case. The function is called from DeviceInputSystem.pollInput, which in turn is called from InputManager, up to 11 times, per input change!! (And looking at this, it might be multiple times for some inputs). Just moving the mouse over the scene for one of my projects leads to getGamepads being called more than 100 times per frame, for a scene which has no intention of handling gamepad inputs at all.

Surely checking gamepad state should happen once per frame (as the comment implies), and just loop over all connected gamepads (which are stored, so no need to even call getGamepads), instead of checking (multiple times) if every single input event (all of which from what I can see are pointer or keyboard events) is from a gamepad.

I’m curious what the rationale behind using the device input system (pr here) is, seeing as for the general use case of mouse and keyboard events on the web, it seems to add a lot of convolution and indirection.

@Deltakosh I will say here that I’m disappointed in the attitude towards opening issues directly on github. It seems like you want github to only be the domain of core members. I can understand wanting questions and general discussion to occur on the forums here, but to disallow bug reports without first going via the forum goes a bit far.

It is far harder to search for bugs on the forum to see if something has already been reported, and even harder to find if it’s been resolved, and impossible to do so at a glance. There is no distinction on the forum between open and closed issues.

Furthermore you alienate developers by closing issues in such a manner, and put off potential contributors. How many such closed issues don’t end up on the forums at all, and therefore aren’t looked into. If I didn’t repost this issue here, would the problem just continue to exist until someone else stumbled across it? Pretty much all developers have github accounts, and are used to using github. Github is designed for exactly this use case, and should be used as such.

2

We have rules. They are CLEARLY stated in the issue template. We DO NOT want issues or whatsoever on the github if it is not validated. We used to have a lot of bugs which are actually people not reading the doc or doing something wrong on their side.

I’m disappointed in the attitude towards

And I’m disappointed when people just ignore rules we try to establish. So we are even

The main reason is that if we explain on the github we end up having too many places for people to search. By maintaining ALL the discussions on the forum we ensure we have one unique place for people to search.

There is no distinction on the forum between open and closed issues.

Wrong. They are marked as answered. Furthermore, every time we confirm a bug or anything that will lead to an issue, we reference it here and create an issue. So you can still look it up in Github if you need. So everyone is happy.

I’m sure your issue is a real bug and so I can ping @PolygonalSun to investigate

Furthermore you alienate developers by closing issues in such a manner,

Sorry about that. This is not the goal. And we always look at the issue anyway (in order to not lose them). But I should not say it out loud.

Github is designed for exactly this use case, and should be used as such.

Let’s agree to disagree then as I already explained why we want only one channel to communicate with the community

3

This is definitely a good question for @PolygonalSun (Hence another reason to chat here so everyone can see it or participate)

4

So the original intent behind the DeviceInputSystem was to create a contract that could be used with both the Babylon.js side and the Babylon Native side. Since the original input system was so heavily rooted in using DOM elements (which are unavailable to Babylon Native), we had to create a bit more of a complex solution. Some of the growing pains with this system are in the removal of these DOM specific things and abstracting it enough to allow for Babylon Native to use the JS side’s code with minimal to no changes.

Unfortunately, there’s still some work to be done and based on your findings, a ways to go for optimization. PollInput should just be a simple array lookup (except for gamepads) and I can already see a better way to handle the logic that I’ll be pushing in the next few days. That being said, I do appreciate you bringing up this stuff so if you see anything input related, just tag me on it and I should be able to look at it and address it.

4 Likes
5

As for the IE issue with navigator.getGamepads being undefined, I’ll make sure to put a check in there for that as well.

2 Likes
6

I can understand having rules, and as I said I totally understand wanting questions and general discussion in the forums. Redirecting such discussions to the forum and closing the issue for such things is totally fine, and doing so is also fine if it’s a case of just needing to read the docs.

And I’m disappointed when people just ignore rules we try to establish. So we are even

This isn’t a competition or fight, there’s no getting “even” here.

Wrong. They are marked as answered. Furthermore, every time we confirm a bug or anything that will lead to an issue, we reference it here and create an issue. So you can still look it up in Github if you need. So everyone is happy.

This system is clearly not strictly followed. There are many posts in this bugs forum not marked as solved, are they really all unresolved? This seems very unlikely (for example MASSIVE BUG: gizmo + rotationquaternion - #10 by mrlooi, a pr was made and merged, but forum topic was not marked as solved). Github issues are not always made, or a pr is made without an issue ever being opened (see previously linked topic). Issues easily become lost (such as MultiMaterial Solid Particle System Breaks Picking - #5 by jerome, for which no issue or pr seems to have been made, and has probably long fallen off the core teams radar).

I also can’t seem to find a way to filter topics by the solved state (if this functionality exists I’d love to be pointed towards it as it would at least partially address some of my concerns).

And we always look at the issue anyway (in order to not lose them).

I’m glad issues are still looked into, but without an open issue then I can easily see it being overlooked if not addressed immediately.

Let’s agree to disagree then as I already explained why we want only one channel to communicate with the community

Again I understand wanting to have one place people look for information, but bugs are not the same thing, and discussing bugs, referencing commits that might have introduced them, linking to code etc is far better served by tool that is designed for that purpose. At the very least using that tool (github) for that purpose shouldn’t be frowned upon.

@PolygonalSun Thanks for looking into this.

I thought the motivation would be something to do with unifying web and native controls, and can see why this would be desired.

I think the IE11 issue is slightly deeper than just getGamepads being undefined, as setting that to an empty array then exposes the other mentioned issue regarding mouse wheel.

8

I’ll take a look at the mouse wheel too.

1 Like
9

The process now would be that either @PolygonalSun or @sable create the issue on the repo and link to this discussion

10

You may have missed that part:
Furthermore, every time we confirm a bug or anything that will lead to an issue, we reference it here and create an issue. So you can still look it up in Github if you need. So everyone is happy.

I did not miss this part. I’m saying that opening a valid issue on github should not be frowned upon, even if you’d rather topics were made here first. The focus should be on resolving issues, not on making sure they’ve been posted in the right way.

Sure we are not perfect. I encourage everyone to mark an open bug or question as solved though

This is my major point though. Github makes it trivially easy to keep track of unresolved issues, and close them once they are resolved. Issues don’t get lost via the passage of time (perhaps unless many unresolved issues accumulate).

The process now would be that either @PolygonalSun or @sable create the issue on the repo and link to this discussion

Why not just reopen the issue that was closed?

11

Glad to continue this discussion in pm to not pollute your issue

12

Sure that will work (done)

13

The point is “valid” here. Maybe what we can do is asking for a forum discussion link before closing the issue, giving the user a chance to provide it.

That being said I would have thought that mentioning it in caps in the issue template would suffice

14

The point is “valid” here.

If it’s not valid, then close the issue, no harm done.

Encouraging people to use the forum is one thing, flat out refusing to engage with issues unless they’re on the forum first is another. If a user’s not sure if something is actually a bug then yes posting here first to verify could perhaps make sense. When it’s clear this is not the case (and clear that some investigation has taken place) then it seems unnecessary.

If I find what I think is a bug, I’ll first investigate the codebase, then search the github repository, and then search the forums. Having issues on the forums instead of on github doesn’t make them easier to find (and as previously stated, makes it easier for them to be overlooked or forgotten).

If all discussion should happen here, why have issues at all? Should I not use the reopened issue for any further discussion?

15

We want only one place for discussion: here. If someone is looking for reasoning behind DeviceManager, I want people to only look in the forum.

You are a really rare developer unfortunately:)

16

Why having issues? To track our work (bugs, validated features)

Our= core team and everyone who wants to contribute

17

Yes the discussion of the reasoning behind DeviceManager was a bit of an aside, and perhaps more suited to a discussion forum, but it was related to the issue at hand.

If you really want to maintain this stance of no issues before a forum post, I think better tooling is needed. Something that would allow you to copy the issue to a topic here, link the github issue, add a link to the forum post to the github issue, before closing it (and then can reopen that issue later if issue was valid). Some automation between closing an issue and marking a topic as solved is also needed.

A way to filter for only resolved or unresolved issues on this forum would also be vital, and the number of unresolved issues here should fairly closely match that of github. It should also be enforced that an issue is made on github, not just a pr or fix made.

This still seems very clunky to me compared to just being able to github issues as they’re intended. You also lose the ability to see when commits were made (and more importantly, when in the context of the discussion).

I maintain that closing issues and pointing to the forum with no regard to the validity of the issue does more harm than good, pushing away the few that have opened a legitimate issue on github.

Having rules is fine. The blanket enforcement of them is not. While yes I disagree with the forum first rule (and have opened issues on github in the past without them being closed for breaking it), I can in the future post here first.

18

I will make sure to be a bit less harsh for sure next time:)

As I said we had so many random issues in the past that I became a bit too harsh. It was certainly not meant to be mean against you.

Also I’m open to any help in tooling or whatsoever that could help smooth the process

19

I’ve got a PR out for the undefined calls and the mousewheel issue: Minor fixes for IE 11 support (DeviceInputSystem) by PolygonalSun · Pull Request #10013 · BabylonJS/Babylon.js (github.com)

1 Like