Edge does not fire wheel events when scrolling using the 2-finger scroll gesture on a Precision Touchpad

Issue #7134034 • Assigned to Matt R.

Details

Author
Bryan C.
Created
Apr 6, 2016
Privacy
This issue is public.
Found in
  • Microsoft Edge
  • Internet Explorer
Found in build #
13.10586
Reports
Reported by 48 people

Sign in to watch or report this issue.

Steps to reproduce

Diagnostic data is available and has been analyzed automatically with the most relevant hints listed to detect the underlaying issue. Please find the insights listed below.

To Reproduce:

  1. Use a Win10 device with a precision touchpad (Ex: Surface Pro 3/4/Book) or use a touch-enabled Win10 device with the on-screen touchpad that launched with the Windows 10 Creator’s Update.
  1. Use this jsfiddle: https://jsfiddle.net/0z8mvewo/
  1. Point your mouse cursor over the image and try to scroll using the 2-finger scroll gesture.

Expected Behavior: The script should capture the “wheel” event (which the Edge Platform Status Page claims is supported), prevent it from scrolling vertically (the event handler calls event.preventDefault()), and instead use the wheel scroll delta to animate the image moving horizontally left or right by the number of pixels the user scrolls with the 2-finger gesture.

Actual Behavior: Edge does not fire the “wheel” event, and hence the wheel event’s default behavior is not prevented. Instead, Edge just scrolls the page vertically. The script does not execute.

This bug is specific to Edge when using Precision Touchpads (including the new on-screen touchpad): Edge properly fires wheel events for 2-finger scroll gestures on non-precision touchpads such as modern Synaptics touchpads like on the HP Spectre 360, regular mouse wheels on external mice, and vertical scroll-swipe edge areas on legacy touchpads. The only trackpads that have this issue are PTPs, and the new Windows 10 on-screen Touchpad that launched with the Windows 10 Creators Update. I know that PTPs are different under the hood, but users do not care. They expect consistent functionality. Edge consistently honors the 2-finger scroll gesture by scrolling the page and firing the “scroll” event. It simply fails to fire the “wheel” event. That creates inconsistent behavior that is confusing to the user who has no idea why their Surface’s touch-pad doesn’t behave the same way as their friend’s HP does. Interoperability: Try the same jsfiddle in any other Browser (Chrome, Firefox, Brave, Opera) on the same machine using the same Precision Touchpad. You’ll see that the “wheel” event fires as expected, and the browser properly respects calls to event.preventDefault(). Work-Around: There is NO WORK AROUND until this is fixed as there isn’t even a proprietary Edge-Only event to hook into to prevent the default behavior. I Need You to Feel My Pain: Seeing as 2-finger scrolling has been the standard scroll-wheel gesture for trackpads for close to a decade now, it’s very frustrating that this bug has been ignored for so long (I first reported in the IE days, then again in the Spartan days, and now we’re more than a full year into the Edge days… still no announced plans to fix).Others Who Are Feeling the Pain:

  • This breaks EVERY web experience that relies on wheel events * Web GL Engines & Games like Unity * Custom cross-platform touch-scroller shims like iScroll * Windows 10 apps built on Edge like Flipboard * Windows 10 XAML apps that use EdgeHTML web views and rely on the wheel event to scroll the outer canvas, like the Windows Insider’s Feedback Hub. * Wheel-based zooming on Bing Maps or Google Maps * And obviously, some of my own products I know that the PTP is different under the hood… But users don’t care: As I’ve said, this has been a pain point I’ve been reporting to Edge PMs for years now so I know you know of it. I wanted to file an official bug so that I can track progress, and hopefully convince you it’s worth fixing before you try to create an entirely new standard for precision touchpads (as someone on the Edge team told me they were planning a few years back)… That is a lost cause, and as the past years have shown, will never get off the ground. The thing is, a new standard for precision touchpads is just not something any other platform, or even browser, needs. There is no motivation to create a new standard for it outside of Windows 10 and Edge. Every other browser solved the problem by simply firing the wheel event as expected. Why not just do the same?

Please. And Thank You!

Attachments

0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Rick J.”

    • The platform status page shows this as working. It’s not.

      https://developer.microsoft.com/en-us/microsoft-edge/platform/status/dom3wheelevents

    • I can reproduce it :)

    • Can reproduce!

    • Also able to reproduce; totally destroys scrolling in many web-based text/code editors such as Ace.

    • Sure enough… this breaks ACE too. To verify, just navigate here: https://ace.c9.io/#nav=about and add a bunch of new lines to the code editor until the scroll bar appears. Won’t let you scroll with the precision touchpad.

      This effectively breaks code editing on:

    • This also breaks the new Microsoft CaptionBot.ai site, which lets you scroll through images to try with your mouse wheel… but it doesn’t work in Edge on Surface devices with Precision Touchpads because of this bug.

      To replicate:

      • Browse to the CaptionBot.ai website
      • Point your mouse over the strip of images
      • Try to scroll through them with the 2-finger gesture on a Precision Touchpad
    • Microsoft Edge Team

      Changed Assigned To from “Rick J.” to “Ibrahim O.”

      Changed Assigned To to “Rick J.”

    • Also doesn’t work on a single page scroll plugin like http://alvarotrigo.com/fullPage/

    • Microsoft Edge Team

      Changed Assigned To to “Sermet I.”

      Changed Assigned To from “Sermet I.” to “Andrew B.”

      Changed Assigned To from “Andrew B.” to “Matt R.”

    • This is still broken in the new Edge Build in Win10 14332.

    • This is still broken in the new Edge Build in Win10 14342.

    • So the behavior seems to be starting to change in Build 14352!

      It now seems to fire the wheel event… But ONLY if I scroll UP with a quick 2-finger swipe, and only AFTER I’ve released and the momentum from my swipe takes over… The fired event however ignores the event.preventDefault(); and event.stopPropagation(); calls, resulting in the page’s normal scroll behavior still happening.

      Soo… very happy to see some progress! Hoping this wasn’t an accident but is a sign that a true fix is in the works. Would love to see confirmation from one of you lovely Edge Engineers on this issue.

    • Still broken in 14361

    • Seeing some new progress in 14366. Now if the main scroll bar is at its limit, the wheel event fires… However it still ignores event.preventDefault(), resulting in the main window scroll bar handling scroll when ever it isn’t at the end of the direction you’re scrolling in.

    • A little regression in build 14376. I can still get the wheel event to fire, but only if I swipe 2 fingers to scroll very quickly again and again and again when at the upper edge of the window’s scroll bar. Still ignores event.preventDefault.

      Still hoping a fix for this can make it into the anniversary update 🤞🤞

    • Seconding that sentiment, for what it’s worth.

    • 14388 brings us back to the way it was working in 14366. Seems we just need it to be able to fire the event even if the outer page is not at the scroll limit, and to properly respect event.preventDefault(). Still crossing my fingers for a fix by 8/2!

    • No changes in 14390 and 14393 it seems. 2 weeks & a day 'till launch. I’ve got a case of beer with your name on it if you can fix this before the 1607 launch, Matt!

    • Damn… 14393.5 (the RS1 “Anniversary Update” RTM?) still doesn’t handle precision touchpads like any other touchpad. Would love to see a fix for this make it out in a patch before RS2.

    • Still a problem in 14393.51

    • Still a problem in 14393.82

    • lol, no wonder most have moved on to browsers that just work. Seriously Microsoft? This is core functionality.

    • Still a problem in 14393.105. Too bad so many sites are broken on Microsoft’s own hardware and software as a result of this bug, seeing as all Surfaces released in the past 3 years shipped with precision touchpads. Too bad Microsoft continues to deprioritize this issue even though every single other browser has solved it.

      At least now that Chrome 53 fixed all the battery and performance issues Chrome had, users have a great alternative while MS continues to ignore this critical bug.

    • What is your ETA?

    • Same problem in 1493.187.

    • Also posted to the user voice page where it’s now the 2nd hottest item on the list. Please please please just fix this!

      https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/15951508-support-wheel-events-for-2-finger-scrolling-on-p

    • Threw my 3 votes at that. I’d vote every point I have if I could. I’d really love to use Edge as a primary browser but given that it doesn’t work with so many modern usecases that involve scrolling, I’m stuck opening a second browser and optimizing my products for other them instead. The fact that we got an extension system before we got functional scrolling is a bit baffling.

    • Microsoft Edge Team

      Changed Title from “Edge does not fire wheel events when scrolling using the 2-finger scroll gesture on a Precision Touchpad” to “Edge does not fire wheel events when scrolling using the 2-finger scroll gesture on a Precision Touchpad”

    • Updating title since the comments have pushed the info regarding it impacting surfacebook and other precision touchpads down a bit.

    • Looks like this bug may also be breaking scrolling in the “Announcements” section of the Windows 10 Feedback Hub… assuming this app was built with HTML/CSS. Scrolling with a mouse wheel works fine when the pointer is over the content of an announcement, but does not work if you use a precision trackpad unless you move your cursor to the far right (where it’s not over the web view that shows the “Announcement” article contents).

    • Still broken in 14971. Blows my mind that you can build new support for Web VR but STILL can’t fire the standard wheel event…

    • Ridiculous that this problem still hasn’t been addressed or acknowledge. It puts a dent on the Microsoft effort for good scrolling on the windows platform. Still hasn’t been fixed on current windows release for Surface Pro 3

    • How can you not have a simple thing like scroll wheel support for trackpads on Edge? I would’ve actually used Edge if scrolling didn’t cause all kinds of havoc through my trackpad.

    • Still broken in 14986. How many years can a feature that’s supposedly supported according to your web platform status page go broken? Nobody at Microsoft cares. That’s clear now. Nobody cares.

    • Absolutely ridiculous. I’d love to tell people that Edge is decent, but I’m definitely not sticking up for a browser that doesn’t scroll correctly on MS’ own flagship laptop. How this issue still exists is completely baffling to me.

    • This is indeed getting ridiculous. What are we supposed to to ? Display a modal telling the user that our web app does not support Edge ? Your problem Microsoft.

    • Ok, Edge PMs… You’ve had years to fix this while it was only affecting Microsoft’s own hardware. Now Lenovo is putting precision touchpads in all their new laptops. Time to get your shit together AND FIX THIS!

      http://www.theverge.com/2016/12/28/14094604/lenovo-thinkpad-enterprise-pc-kaby-lake-windows-hello-usb-c

    • STILL broken in build 15002.

      …And while I can use my mouse wheel to vertically scroll to make the new tab preview slide left and right, the precision trackpad requires me to go side-to-side. Related?

    • Still broken in 15031

    • Still broken in 15048

    • This bug also appears to affect the on-screen touchpad coming in the Creator’s Update (which presumably uses the same internal APIs as the Precision Touchpad). I’ve opened another bug for this one here:

      https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10523255/

    • That’s hilariously awful how a known issue cannot be fixed by Microsoft even in insider builds for 2 years…

    • Whenever a change log comes out and I read through the new features and fixes I have to laugh at the decision-making process knowing that this is still open.

    • Makes you wonder if “Matt R.” still works for MS. Or if MS developers actually use their own products.

    • Hey look… an official Edge Blog post claiming “wheel” event support in Edge. WT actual F:

      https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/

    • Still broken in 15061

    • One of these days this bug will not longer drive me insane.

      Because I’ll be dead from old age.

    • Still broken in the Creator’s Update build 15063. Maybe they’ll get a chance to get to this before the next major release at the end of the year? One can hope.

    • Bryan C. I’m on Surface Pro 4 and it definitely has a Precision Touchpad. I dont have any problem in Edge with it, at least on the websites that I use. I never faced this issue. Although, on Feedback Hub app at the Announcements page I cannot scroll opened news with my touchpad.

    • But jsfiddle script seems like to work sometimes only if I scroll up or left/right but when I scroll down it will just scroll the page

    • HI Nikita… To clarify, as you seem to have missed it, the issue is not that it doesn’t scroll (it does), but rather that it doesn’t fire “wheel” events when scrolling (as it’s supposed to… and as every other browser does… and as the platform status page says it does).

      The jsfiddle I wrote demonstrates this by attempting to catch the “wheel” event, prevent the default behavior (scrolling), and animating horizontally instead.

      It works fine on every browser except Edge. It works fine on every Touchpad except for PTPs (like in your Surface Pro 4).

      If you scroll back up to my comment on May 26, 2016 about build 14352, you will see that I noted, as you now did, that sometimes Edge will now fire the wheel event IF you’re at the extremities of the outer scroll box in such a way as to cause edge (or windows?) to simulate the over-scroll momentum “bounce” effect. But even in that case, it still does not honor calls to event.preventDefault().

      I know Microsoft is aware of this bug as I’ve had several (some friendly, some not-so-friendly) conversations with a half dozen different people on the Edge team about it. The line I keep hearing is alwasy "Oh, you’re right… let me check on that", only to have them come back after talking to whoever is in charge of deciding if they’ll ever fix this to tell me that "It’s hard". Or "Precision Touchpads are different under the hood, so they should be treated differently".

      The first excuse I get. If that’s the roadblock, surely the years since I’ve started reporting this have been enough procrastination… especially now that PTPs are getting pretty damn popular, and the Edge team has done a very good job of fixing the crippling performance issues (seriously… the Creator’s Update is night and day in terms of performance. They did a killer job there).

      The second excuse (“we should treat PTPs differently”) is just, I’m sorry, total BS. Users DO NOT CARE that their trackpad is a Precision Touchpad or a Synaptics Touchpad. They just care that it WORKS CONSISTENTLY AS EXPECTED. If you’re going to support the 2-finger scroll gesture (as PTPs do), then you need to make it fire the wheel event like every other trackpad does when scrolling with a 2-finger scroll gesture, and every other browser does. For some unknown reason, there are some very very stubborn Edge PMs (or maybe just one very important PM? who knows) who disagree with this and insist on treating it differently, even after the recent blog post I linked to above detailed how one should properly handle “wheel” events for 2-finger scrolling gestures (in which the author actually said they’re testing using a Surface Book… meaning he MUST have ran into this issue while testing)… So clearly they “GET” that 2-finger scrolling is the same to the user as mouse wheel scrolling. The visual behavior is the same… so much so that you, Nikita, misunderstood this bug and thought it worked fine… But for devs who want to change wheel behavior for any number of reasons (of which I’ve listed many over the past year or so), you simply can’t if your users use Edge. Such a shame.

    • Changed Steps to Reproduce

      Changed Steps to Reproduce

    • Changed Steps to Reproduce

      Changes: When I first filed this bug on the Edge Issues site, it was new and the markdown parser was broken, removing line breaks and merging bullet points together. Now that the markdown parsing has been fixed and the site lets me make edits, I’ve taken the time to better format the steps to reproduce to improve clarity, better note that it affects Edge’s claimed standards compliance, and to (hopefully) better present the case for why this is important to fix sooner rather than later.

    • Changed Steps to Reproduce

    • Happy birthday to this bug (even though the displayed date doesn’t reflect how long it’s really existed). Cheers to the eater-of-productivity and the cause for 90% of my Chrome use!

    • This is very broken. We see swipe and browser zoom (no wheel events). We don’t want either of these in our browser-based app. We’ll leave our nag screen up that Edge is unsupported until this is fixed.

    • Here’s a fiddle with the Edge issues:
      https://jsfiddle.net/alecazam/my6gntrr/

      touch-action also frustratingly doesn’t apply to touch-pad, and pointer events don’t seem to have a method to identify that. Edge has to send down wheel events or we can’t preventDefault. Also the devicePixelRatio conversion needs to be document, because I can’t figure out the inverse relationship (it’s not just deltaXY / dpr).

      I can’t think of any web app that wants the default browser zoom and swipe behavior on the touchpad. This is also confusing to our users since the XPS 15 (with precision touchpad) can’t do our pan-zoom or pinch-zoom behavior, but the Razer Stealth (without precsion touchpad) can.

    • It looks like this also does not send gesture start/change/end events. I’m all for Microsoft adding pointer events, but those don’t apply to touchpad. This simply needs to be fixed, and so does this:

      https://answers.microsoft.com/en-us/windows/forum/windows8_1-tms/microsoft-precision-touchpad-not-very-precise/ca01bc04-0db7-4241-bff9-192cfb5af012

      The driver for my Samsung Notebook 9, and a XPS 15, and the Surface, yadda, yadda all have a horrible h/vscroll lock (ignoring movement in the other direction), and making diagonal panning impossible along with precise creative tools editing. You can see this in browsers and in regular apps on these machines, but non-precision touchpads work fine. Once you move past the un-settable threshold, then panning works, but you lift your finger and it stops. Several individuals on that thread have pointed this out to Microsoft to no avail (like this ticket).

    • Had a good time at Microsoft’s Build 2017 conference this past week where I met a couple Edge engineers and some other Microsoft developers. Lots of very smart very nice people, one of whom (Brian Terlson) works on the ECMAScript Standard.

      Brian took a look at the bug, confirmed Edge is not interoperable, said it “seems bad” and that he’s "pretty sure this is the cause of some weirdness I’ve seen in the past".

      When I mentioned I was told that some believe 2-finger scrolling on the Precision Touchpad should be treated differently than other touchpads because the precision touchpad is more powerful and should thus be given its own API, Brian said "I mean, that’s all well and good, but it should also at a minimum meet user expectations of how trackpads work", which has been my argument for more than a year now.

      So, good news everyone. Brian, the man at Microsoft who works on the JavaScript spec agrees with us that this is a problem that needs to be fixed.

      Now on to the bad news… Brian, for all his good intentions, does not work on Edge, and thus does not have final say (though he told me he’d try to bring some attention to the problem).

      Absent from the Build conference was anybody willing to defend the decision thus far not to fix this bug, and it was made clear that the person holding up any improvements here is Matt R. The very Matt R this bug has been assigned to since Apr 21, 2016. I actually met someone who told me Matt is his PM who seemed very surprised that this wasn’t a priority given the number of “Me Too” votes it has received over the past year.

      I was told by Kyle Plufg that Matt has a “nuanced” view as to why he doesn’t want to fix this bug and that he doesn’t feel he can defend his decision.

      Matt, I’d hope you’re getting notifications about the comments we leave here as you’re assigned this bug. If you’re reading this, I hope I can convince you that this continues to be a pain point that prevents many of us from getting our apps to work the way they do in every other browser. I’d love to hear your nuanced take on the issue. And short of a proper fix, I’d love to get an option for a work around (even if that means going down the old IE6 path of building a new Edge-Only feature that doesn’t follow any spec because you think you can do better than the spec). I’m willing to play by your rules as it seems you have ultimate power on this issue, so if that’s the route you want to go… let’s do it. Let’s just make some progress. Nobody I talk to can trump your “nuanced” view on this issue, so… Congrats. You’re a powerful guy. Now please, use that power to make some progress. It’s time.

    • Thanks for the update Bryan!

    • Go Bryan! This is really something critical to fix. We’d like to say Edge is supported for our PWA, but this and the initial h/vscroll lock in the Microsoft mouse drivers (across all apps) make the Windows “precision” touchpads unusable IMHO. Microsoft has a competitor with a very good example of how a touchpad should work.

    • Hi,

      We run a SaaS called Remember The Milk, which includes a fairly complex web app that painstakingly implements native-like scrolling across platforms.

      We’ve had a couple of reports of users not being able to scroll in our web app on Edge but we’ve never quite understood why since it doesn’t happen in VMWare or a Windows laptop with a Synaptics trackpad.

      So… we got a Dell XPS 13 and yup, you can’t scroll in Edge on it due to whatever this ticket is.

      It works in Chrome. It works in our Electron based app.

      I attached a mouse and it works fine.

      I spent a couple of hours trying to figure out if there’s some hacky work around but there are no events sent to the browser. No touch events, no pointer events, no gesture events.

      And then I ended up here.

      This is kind of a weird bug to have in a major shipping browser. Why does the pointing device matter? I can’t say I spent the time it takes to read every comment on here, but yeah, I guess the TL;DR of my comment is: +1, please fix.

      Thanks.

    • A positive new development… Patrick Kettner (who works on Edge interop) just told me on twitter that he’s "actively working on a solution for devs who use the wheel event today".

      He says the block has been perf related. Separate threading model for PTPs means cancelable wheel event isn’t currently possible.

      If any of you use Twitter, might be good to chime in and give him some kind encouragement to let him know how important this is to you. Hopefully they’ll be able to get this baked into the bits that ship for the Fall Creator’s Update later this year.

    • +1 to this bug - ran into this building a UWP app ugh. I’m surprise it’s been around for so long and still not addressed. Now I understand why there’s so much hate for IE.

    • I can reproduce this bug on a Microsoft Surface Book product with precision touchpad. Please don’t let Edge go extinct like Internet Explorer. Let’s squash these bugs, Edge team!

    • I can confirm this issue. In my case, when accessing my Synology NAS Control Panel, I cannot scroll using the 2 finger gesture.

    • More new Laptops this bug cripples:

      • Surface Laptop (Which can’t event install chrome to work-around this issue without upgrading to Win 10 Pro)
      • Surface Pro (2017)
      • Razer Blade Stealth
    • This is just ridiculous. The almigthy Microsoft can’t fix this issue for years.
      Huge thanks to you Bryan for not giving up.

    • This is embarrassing and unprofessional. Lots of people reporting an issue and instead of finding a solution, just ignore it? Seriously? I would be fired if I worked this way, and rightfully so. After seeing the way this issue is being handled, I’ve lost all hope for Edge. Surely there are other issues that are just being ignored. Extremely disappointing. Why even bother making Edge? It makes no sense

    • This is especially annoying because Edge also has an issue with jittery background images with fixed positions when scrolling that the only be workaround is adjusting for the wheel events wheelDelta data. https://stackoverflow.com/a/28529089

    • You are a very funny guy :D
      …"we believe that the quick fix would be more detrimental"…

      Yet the problem exists for more than 1 year. Maybe You should have addressed a quick fix a year ago, so you would have a solution by now.

    • I’d like to start by thanking everyone for taking the time to let us know how painful of an issue this has been. Your feedback is key to helping us understand how this impacts real sites and developers.
      We have been discussing this at great lengths internally to close on the best path forward before reaching out to the community, and I wanted to share an update on our plans. Before jumping into solutions, however, please allow me to set some background context. Precision touchpads (or PTPs) are handled by Windows’ input stack in an entirely different manner than legacy touchpads. Input from PTPs is fed into part of our touch input stack, giving users improved performance, physics, and functionality compared to non-PTP devices. As a downside of this, however, we are not able to fire wheel events, a fact that has led to the issue you are all painfully aware of.

      Our first idea to fix this was to remove the PTP code path, allowing wheel events to be fired for PTPs. This would close the interop gap between PTP and legacy touchpad devices, but this fix would come at several costs: 

       1. Consider a site with a map control. A user interacting with this map via touch would expect several things to be true. For example, they’d expect to be able to pan the map by dragging it and they’d expect to be able to zoom the map with a pinch gesture. This paradigm would break down on a touchpad if we sent wheel events, however, since a two finger pan gesture in the y axis would result in a zoom, but a two finger pan gesture in the x axis would do nothing. Furthermore, any complex gesture (such as pinch to zoom) would still be broken and developers would have no way of addressing this since they do not have fine-grain control over the touchpad. 

       2. Earlier this year, we announced our effort to improve scrolling performance on the web via independent scrolling (https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/). As outlined in this post, attaching global wheel listeners prevents Microsoft Edge from following its off-thread scrolling code path. Despite the known performance impact of this pattern, our web crawler has provided us with data that shows that approximately 20% of all websites attach global wheel listeners. This means that if we were to fire wheel events, PTP scrolling would take a performance hit on one out of every five sites, leading to a subpar scrolling experience for users.

       3. Adding to the above, firing wheel events would cause our mouse wheel code paths to be executed. These call substantially different APIs under the hood, which would cause scrolling on the same 20% of sites to feel jittery due to a lack of continuous animation and physics calculations. (And that’s not counting the jittery scrolling issues that others have brought up on this thread, which believe me, we know are bad)

      We’re all developers, and we want to do what’s right for our users. This is why we understand that this functionality cannot remain broken for you, but it is also why we believe that the quick fix would be more detrimental to users’ overall scrolling experience both in the short and long term. 

      As a result, we’re currently investigating ways of exposing pointer events for touchpads through the web platform. Our hope is that by doing so, sites with existing pointer listeners would light up with no extra work, developers could write custom recognizers to handle more complicated touchpad gestures, and users would continue to have the best scrolling experience possible. 

      We appreciate your patience while we continue to work with our input team to find the best path forward. Since this change is still being designed, I welcome any feedback you may wish to provide. Please feel free to comment directly on this bug or to reach out to me via Twitter @_scottlow. Thanks again, and I’ll keep this thread updated throughout the design process!

    • Is this also an issue with trackpad scrolling in Safari on a MacBook? If not, I wonder how they did it

    • Scott,

      First, thank you for letting us know you’re working on this. I’m very happy to hear this is finally getting some attention.

      I’m a bit frustrated that this new plan to use Pointer events is the exact plan I heard from an Edge PM more than 2 years a go at //Build2015 when I brought this up during the Q&A of one of the Edge Sessions (or was it still Spartan then? I don’t remember). At the time I said this will never get off the ground as nobody needs it… They just need the spec. And here we are 2+ years later and it’s still not off the ground. Anyway. That’s neither here nor there… Let’s move forward. As you said, we’re all developers here who want to do right by our users.

      Your mentioning the ability to use the traditional wheel code path for PTPs when a site hooks into the wheel event (with the option to call preventDefault()), while using the optimized PTP path for sites not hooking into the wheel event sounds like a brilliant win win solution. Genius! And something that should be quick to accomplish given the work you’ve already done on this and pointed out in that blog post. I was thrilled when I was reading this part of your response. THIS is what we want. THIS is what will solve everything! Needless to say I’m very disappointed to hear you don’t want to take this path.

      Please hear me out. I hope to change your mind. Happy to get on a skype call to discuss with you & the rest of the team too if it would help you better understand the opposing viewpoint.

      I’m very concerned that this plan is akin to the mistakes of IE’s past where you do your own thing instead of just following the standard spec.

      I understand that your primary concern is that this will hurt scrolling on 20% of sites… But I’d say, respectfully, that the massive omission in your reasoning is the fact that that means 20% of sites are currently broken as you’re not firing the wheel event they’re expecting.

      I presume your thought process is that the user will blame Edge instead of the site for less smooth scrolling, and you don’t trust the site developers to update their code as necessary. You may be right for those who only use that 20% of the web… and if scrolling code without PTP optimization was a truly unbearably choppy experience… But here’s the thing. I have a non-PTP laptop too… and scrolling on it with wheel events firing is really not that bad. Side by side you can definitely tell the difference… But if your machine simply doesn’t have a PTP… you don’t think twice about scrolling on it (because it just works). In fact… as 80% of the web doesn’t hook into wheel events, it’s pretty clear that it’s a site issue for the slightly choppier 20% that do (and get the slower process, albeit with the functionality they presumably need). Good to remember that most laptops don’t have PTPs and you don’t see an outpouring of bugs on this site about scrolling being choppy from them.

      I get that under the hood the PTP is more like a touch screen and you + the rest of the Windows team have all done a great job and put in a lot of work to make that super responsive and you don’t want to give that up… And I realize that this fact means you can potentially enable new cool things like custom gestures via Pointer events, and that’s exciting for the scenarios you describe (ex: pinch to zoom in maps).

      But even after you do all the work required to enable these custom PTP Pointer events, consider the following:

      1. Who, beyond the 40 or so people who are watching this bug are going to know about it and use it? It’s a custom Edge-only feature that only applies to the people with PTPs.
      2. Do I have to roll my own 2-Pointer-Event vertical/horizontal swipe gesture detection code? Doing that well is NOT easy (as I’m sure the PTP gesture team knows as it wasn’t anywhere near as good as it is today when it first came out).
      3. It doesn’t solve the problem that the wheel event isn’t firing for the 20% of sites that you say are expecting it today.
      4. Users expect scroll gestures to zoom on maps today. They don’t expect pinch gestures too as they’ve never worked properly. I get that enabling this scenario is exciting… And you know what… you should probably do it eventually. But not before fixing this interop issue that’s breaking 20% of the web for PTP users today.

      So, if you want to do the pointer event system, I say great! Go for it! Sounds cool! … Eventually. Because it also sounds like it’s not going to make it into the Fall Creator’s Update (or perhaps not even the next release)? Why does such an API have to be exclusive of the standard DOM3 wheel event API that Edge claims to support? Why can’t you do both? And start with the obvious one that actually solves the real problem first, instead of building a new tool just for sites that want specialized gestures beyond scrolling.

      So… that’s my ask. Please don’t do all this extra work at the expense of not ALSO firing the standard wheel event for developers who need it and don’t want to have to write (and more realistically, won’t know they have to write) Edge-And-PTP-specific code just to be able to use an event that all browsers are supposed to support out of the box. Many devs today don’t even realize their site is broken for their users with newer PTP laptops as they don’t have a PTP on their dev machine.

    • I’ll just add that I’ve noticed a theme where you try to protect users from lousy web developers who write bad code by crippling good developers who know what they’re doing. I also saw this in Edge’s decision to break responsive websites in tablet mode by ignoring the viewport meta tag and/or CSS and just zoom the desktop sites way out, making them tiny… The reasoning? Some poorly written sites misused (the admittedly flawed) viewport and didn’t look right if Edge respected it.

      At the end of the day, you need to let web developers take responsibility for their site’s performance, and live up to the spec you claim to support. Otherwise we’ll keep repeating the mistakes of the past where you force web developers to have to spend extra time trying to wrestle with IE’s quirks to try and get it to work the same way. Let IE’s mistakes die with it. You’re Edge now. You’ve been doing so well! Own the spec. Embrace it. Yes… it’s good that you want to push it and improve it. But not at the expense of forcing developers to have to handle certain well defined features differently because you thought you had a better idea. It doesn’t matter how much better of an idea it is if web devs still have to do the standard way for everyone else. It’s just creating more work.

      So. Along the lines of letting web developers take responsibility for their own shit… Synchronous wheel events on the window leading to sites scrolling a bit slower is a problem good web developers will notice and research if it’s unintended… And we can all flood stack overflow with the simple answer from the blog post you mentioned: Hook in on the node you need it on, and/or make it asynchronous if you don’t need to call preventDefault(). If they do need to call preventDefault(), then that means they want to block scrolling & are doing their own thing with that interaction… so there’s no choppy scrolling to be concerned about.

    • My biggest issue here is that while we are aware of the differences between PTP and non-PTP touchpads as developers, the vast majority of people aren’t going to be. A general user of a service being told their touchpad isn’t supported makes no sense to them when, from their POV, they’re using the latest and greatest hardware.

      Giving developers powerful and simple tools is great, but if it means the capable developers can’t create even the most basic universal experiences, then the entire point is moot. We really need parity with existing standards and browsers before we go off the deep end with crazy new features and capabilities. Throwing the creators of more advanced UX under the bus to keep the jankier sites running smoothly is not the way to foster better developers and make the web a better place.

      Also incredibly frustrating that a decision that would impact 20% of users is unacceptable when 20% of users are already impacted by not making that decision. Seems like an even trade-off in affected users for a big step forward in compatibility would be a net positive.

    • Another problem with the PTP Pointer event idea… It still doesn’t provide a way to prevent the browser from scrolling as there’s still no way to call preventDefault() on the wheel event. So replacing the 2 finger scroll gesture with another behavior is still not possible.

      Don’t get me wrong. PTP Pointer events sound like a cool idea. And I get that it’s more fun to work on something new than fixing something broken. But it’s just a totally different idea that does nothing to solve the problems caused by not properly supporting the spec in this interop bug.

      And if it’s true that a full 20% of the web is misbehaving right now in Edge on PTP devices, I’d hope that’s a big enough reason to prioritize a fix for the actual issue here.

    • Microsoft Edge Team

      Changed Steps to Reproduce

    • Hi there, I just want to upvote the issue and to confirm it on my ASUS GL502-VS laptop with the PTP. I’m glad to know that the issue is not on my side (eg faulty driver), but the long lifetime of the bug bothers me quite a bit. The main problem for me are maps: google, bing (!) and many others have no way to zoom/pan around rather than clicking ± buttons and click-dragging. That is terribly frustrating!

      I love to use Edge for it being a lot faster than alternatives, but PLEASE fix the PTP issue!

    • I cannot use 2 finger scroll in google spreadsheet. what the …

    • Dear Edge team, this issue has been reported more than 1 year ago already. There have been 2 major update of Windows 10 since. Nothing has changed, bug is still present and is very annoying.

      I’m using Microsoft’s top-level laptop (Surface Book) and I cannot even scroll code in Microsoft’s VSTS. I have to carry external mouse just for this.

      Is it really so hard to fix?

    • Microsoft Edge Team

      Changed Steps to Reproduce

    • Dear Edge Team,

      I was reading the W3C Spec on the wheel event today to try to understand your justification for continuing to omit the wheel event from Precision Trackpads while still claiming you support them on the Edge status page.

      It clearly states (in all caps, no less) that a user agent “MUST” dispatch the wheel event when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action.

      Source:
      https://www.w3.org/TR/uievents/#wheel

      Direct Quote:

      "A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action."
      

      The Fall Creators Update has hit RTM and this is still broken.

      PLEASE PRIORITIZE A FIX FOR THIS FOR RS4.

      Edge’s stated goal is to support web standards. You’ve done a great job in many areas and have lead the way in new areas. Please just fix this very basic building block you’re missing which is apparently (according to your internal stats quoted above) BREAKING 20% OF THE WEB for users with modern windows laptops, including every Microsoft Surface product since the SP2 (and actually, even the SP2 if that user just buys a newer keyboard cover).

    • So I think the best decision FOR NOW is to take the scrolling penalty for the approx 20% of websites and put a kind of warning/info icon in URL bar that says something like “you may experience subpar scrolling on this website, click here to learn more” , clicking on the link would explain why approx. 20% of websites have subpar scrolling, and that’s it’s really not Edge’s fault, it’s a much wider issue.

    • But here’s the thing… they won’t actually have sub-par scrolling if Edge does what they’ve done for other wheel events and differentiate between asynchronous wheel events (which cannot call preventDefault()) and synchronous events (which can call preventDefault())… Edge has already solved this for other trackpads and wheels. They wrote a whole blog post bragging about their work on this. And it’s great work. They deserve to brag about it…

      https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/

      But in practice, almost every scenario where a wheel event is required (vs, just using the scroll event instead) are scenarios where the web developer needs to call preventDefault() so they can implement their own behavior for the wheel that’s different than the default scrolling behavior. There’s no other way to do this without creating a jumping juddering terrible experience. I’ve tried.

    • Just dropping this link about the decision from Microsoft to move its web docs to MDN (https://blogs.windows.com/msedgedev/2017/10/18/documenting-web-together-mdn-web-docs/).

      Quote: "the Web should just work for everyone".

      I just found this good joke too: “Living on the edge – our next step in helping the web just work” (https://blogs.windows.com/msedgedev/2014/11/11/living-on-the-edge-our-next-step-in-helping-the-web-just-work).

      Cry in Edge

    • Time to update the MDN docs for Edge’s support, seeing as “Yes” is clearly not always true:

      https://developer.mozilla.org/en-US/docs/Web/Events/wheel

    • Microsoft Edge Team

      Changed Steps to Reproduce

    • https://blogs.windows.com/msedgedev/2017/12/07/better-precision-touchpad-experience-ptp-pointer-events/#t7B5dcRthcgUPSxg.97

      Will this be a solution to the problem we ar e having?

      Not sure yet, but I am slightly positive.

    You need to sign in to your Microsoft account to add a comment.

    Sign in