Dealing with bizarrely inverted wheel event deltaX in Microsoft Edge browser?

Question

Today I've discovered some very bizarre behavior in Microsoft's Edge browser, where the deltaX values for wheel events is apparently inverted! This was particularly surprising because this is not consistent with every other browser I've ever tested, including Internet Explorer 11 which returns the expected values.

Seeing this issue in action is rather simple, just run the following code, and use your mouse wheel or trackpad.

window.addEventListener('wheel', function(e) {
    console.log(e.deltaX, e.deltaY);
});

For your convenience, I've created a full-page example (snippets are tricky for this):

Fullpage Working Example

Wheeling down gives a positive value and wheeling up gives a negative value as expected in Edge, IE, and other browsers. However, in Edge wheeling left gives a positive value, and right a negative value, the exact opposite of every other browser (IE11 and below included).

I made some GIF videos to show off the issue too, linked for file sizes.

• IE11
• Edge

The question:

Why is it like this, and is there a solution for handling the browser compatibility issues? Is there a way to feature-detect this? Is this behavior a bug, or is it documented somewhere?

The spec strongly suggests this is in-fact incorrect behavior:

If a user agent scrolls as the default action of the wheel event then the sign of the delta SHOULD be given by a right-hand coordinate system where positive X, Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth (away from the user) of the document, respectively.

Notes:

• I've tested this in both a Windows 10 VM and a native laptop, behavior was the same for both.
• I'm reasonably sure this is not related to "natural"/inverted scrolling (off on all systems and VM hosts tested, and only happening on one axis).
• On a side note, I don't know if deltaZ is inverted or even supported to begin with, I lack such an input device.

Bug Report:

I've reported the bug to Microsoft here. It has been assigned to someone, so hopefully it will be fixed.

Mar

Have you reported it as a bug? – Quickie

@Quickie Not yet, I'm not actually sure where do do so. – Enclasp

He, there's even a SO question for that :-) Suggests you should report it here – Quickie

@Quickie Cool, I'll open an issue there later, now that I'm relatively certain it's a bug. Hopefully there is some workaround to be found though, it's pretty nasty because inverting now might mean having to uninvert in the future. – Enclasp

Answer 1

While we await an official response from Microsoft, hopefully in the form of an update that resolves the issue, I have found a way to check if the browser is reporting an incorrectly inverted deltaX.

Edge also added support for the non-standard wheelDeltaX, wheelDeltaY, and wheelDelta properties also found in Chrome. Unlike deltaX, these values are correct, but instead refer to the actual wheel change and not the computed result. While their actual values are of little interest, we can infer the correct sign value from them.

In Chrome, deltaX and wheelDeltaX correctly have different sign values, so when one is negative, the other is positive. This means that if both values are negative or both are positive, the deltaX is incorrectly signed as it is presently in Edge. Therefore we can use this property to detect the incorrectly inverted value and un-invert it.

Here is a wrapper function I created to resolve the issue.

function wheelDeltaX(e) {
    // Get the reported deltaX.
    var r = e.deltaX;

    // In Edge, the deltaX incorrectly matches wheelDeltaX sign.
    // If both value signs match then uninvert it.
    var wheelDeltaX;
    if (
        r &&
        (wheelDeltaX = e.wheelDeltaX) &&
        (
            (r < 0 && wheelDeltaX < 0) ||
            (r > 0 && wheelDeltaX > 0)
        )
    ) {
        r = -r;
    }

    return r;
}

So long as Edge retains the correct signing for wheelDeltaX when they hopefully fix the issue, this should be future-proof.

Mar