Page MenuHomePhabricator

DateTimeInputWidget scrolling behavior is problematic
Closed, ResolvedPublic

Description

Whenever I use the DateTimeInputWidget at Special:NewFiles it's always a frustrating experience. Here's what happens:

  • I click on the input field, which pops open the selector below it.
  • I try to scroll down to the selector (since it's always at least partially below the fold on my screen).
  • Instead of scrolling down, the date spins wildly like a roulette wheel and I end up at some date in the 1940s.

The DateTimeInputWidget should not hijack my scrolling. Instead it should have a simple interface for changing the month or year like DateInputWidget does, IMO.

This is using the standard page scroll gesture in MacOSX (vertical 2-finger swipe) in any browser (Firefox, Safari, Chrome), which triggers the wheel and DOMMouseScroll events.

Event Timeline

DateTimeInputWidget doesn't "hijack" scrolling. It does interpret wheel input much like NumberInputWidget does when the pointer is hovering over an editable field in the widget. It could probably use a change like rGOJUe30f335ac17d: NumberInputWidget: Disable onWheel action unless the widget has focus, although that probably wouldn't help your complaint here since you're focusing and then trying to scroll the page.

I note that both DateTimeInputWidget and DateInputWidget have the behavior of popping up the calendar underneath the widget, potentially off the bottom of the page.

Regarding "a simple interface for changing the month or year like DateInputWidget does", DateTimeInputWidget does have a very simple interface, it's what you're complaining about here. Having an "up arrow" in mw.widgets.datetime.CalendarWidget like mw.widgets.CalendarWidget has would be nice, but it wouldn't solve your problem.

Change 365242 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] DateTimeInputWidget: Ignore wheel when not focused

https://gerrit.wikimedia.org/r/365242

@Anomie: Are you sure it's listening for the right event? I don't have a scroll wheel, I'm just using the swipe/scroll gesture. I assume it should be listening to the "mousewheel" event (which is what the HTML5 number input listens for), not the "touchmove" event (or whatever it's currently listening for).

It listens on wheel, mousewheel, and DOMMouseScroll, just like NumberInputWidget does, which is what was needed a few years ago for browser compatibility. We might be able to drop mousewheel and DOMMouseScroll either now or at some point in the future, as browsers are standardizing on wheel ([[https://developer.mozilla.org/en-US/docs/Web/Events/mousewheel|mousewheel is nonstandard and deprecated]])

I don't know what event your mobile device might fire for swipe/scroll gestures, but it wouldn't surprise me if it's firing wheel to try to be compatible with JS designed for desktop.

@Anomie: It looks like my swipe gesture (on my laptop, not a mobile device) is triggering both the wheel and DOMMouseScroll events. Why don't we switch to listening for the up and down arrow keys instead? I would expect that to increment the field, but I definitely don't expect my vertical swipe to do anything besides scrolling the page.

It already listens for the arrow keys too.

You don't expect your vertical swipe in your unspecified environment to change the number, true, but people do seem to expect their mouse wheels to do so on numeric-type input fields.

BTW, I can't seem to reproduce this bug report on Chrome 59 or Firefox 54 on my Android Nougat phone. Perhaps you should identify where exactly this can be reproduced.

@Anomie: I added a description of my environment to the task description. I also tried hooking up an actual mouse with a mouse wheel and trying that. The mouse wheel also triggered wheel and DOMMouseScroll. I then tried both the swipe gesture and the mouse wheel on a plain focused <input type="number"> field (without any extra JavaScript), and neither triggered the field to increment in any browser I tried (instead, they scrolled the page).

I then tried both the swipe gesture and the mouse wheel on a plain focused <input type="number"> field (without any extra JavaScript), and neither triggered the field to increment in any browser I tried (instead, they scrolled the page).

On my Debian Linux laptop, the "wheel" changes the number in that situation in Firefox ESR 52.2 but not in Chromium 59. @matmarex mentioned in rGOJUe30f335ac17d: NumberInputWidget: Disable onWheel action unless the widget has focus that the wheel changed the number in Chrome at that time.

Indeed, mousewheel to change the value of <input type=number> seems to be gone in Chrome 60 on Windows 10 too. I can't find any commit or bug related to removing it. (I found instead https://bugzilla.mozilla.org/show_bug.cgi?id=949989 for Firefox, which should probably be marked as RESOLVED since the feature exists there.)

(I was testing with this example: https://html5doctor.com/demos/forms/forms-example.html)

Change 365242 merged by jenkins-bot:
[mediawiki/core@master] DateTimeInputWidget: Ignore wheel when not focused

https://gerrit.wikimedia.org/r/365242