User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

Demo page: http://mugifly.github.io/jquery-simple-datetimepicker/jquery.simple-dtpicker.html

To reproduce this issue, put your mouse on one of the calendars and scroll.

Actual results:

Nothing.

Expected results:

The calendar you point to should scroll to another month. This works on Firefox ESR and other browsers

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

This library is using window.sidebar for Firefox detection. Works when dom.window.sidebar.enabled is set to true in about:config

Set release status flags based on info from the regressing bug 1717612

:saschanaz, since you are the author of the regressor, bug 1717612, could you take a look?
For more information, please visit auto_nag documentation.

So it uses DOMMouseScroll if window.sidebar exists and mousewheel if not. And Gecko does not support the latter.

		if (opt.calendarMouseScroll) {
			if (window.sidebar) { // Mozilla Firefox
				$calendar.bind('DOMMouseScroll', function(e){ // Change a month with mouse wheel scroll for Fx
					var $picker = getParentPickerObject($(this));
					
					// up,left [delta < 0] down,right [delta > 0]
					var delta = e.originalEvent.detail;
					/*
					// this code need to be commented - it's seems to be unnecessary
					// normalization (/3) is not needed as we move one month back or forth
					if(e.originalEvent.axis !== undefined && e.originalEvent.axis == e.originalEvent.HORIZONTAL_AXIS){
						e.deltaX = delta;
						e.deltaY = 0;
					} else {
						e.deltaX = 0;
						e.deltaY = delta;
					}
					e.deltaX /= 3;
					e.deltaY /= 3;
					*/
					if(delta > 0) {
						nextMonth($picker);
					} else {
						beforeMonth($picker);
					}
					return false;
				});
			} else { // Other browsers
				$calendar.bind('mousewheel', function(e){ // Change a month with mouse wheel scroll
					var $picker = getParentPickerObject($(this));
					// up [delta > 0] down [delta < 0]
					if(e.originalEvent.wheelDelta /120 > 0) {
						beforeMonth($picker);
					} else {
						nextMonth($picker);
					}
					return false;
				});
			}
		}

Not sure how much this is important, is it still widely used enough to drive a backout or should we instead wait for mousewheel support for general web compat?

Tracking for 102 since this pref is being enabled by default. I don't know how popular a library this is, so hopefully we can get a webcompat evaluation of the impact soon.

It's unclear how to prioritize this from a webcompat perspective right now, as we're not aware of actual live websites being affected by this, and the library seems to not have been updated for a couple of years. But there are 200 or more downloads happening a week, apparently, so it might be best to monitor this one for now and learn more.

In the meantime if we find out there are any live sites being affected, we should be able to quickly add a webcompat intervention, but since the library hasn't been updated for so long it seems as though it may be difficult to get any fixes done at the source.

Thanks! I hope this is rare enough.

We haven't received additional reports with actual websites affected by this, so setting as P3 for now.

Changing the priority to P1 as the bug is tracked by a release manager for the current beta.
See Triage for Bugzilla for more information.
If you disagree, please discuss with a release manager.

Set release status flags based on info from the regressing bug 1717612

The severity field for this bug is set to S3. However, the bug is marked as tracked for firefox102 (beta).
:hsinyi, could you consider increasing the severity of this tracked bug?

For more information, please visit auto_nag documentation.

[Tracking Requested - why for this release]:

Per comment 7 and comment 9, request to denominate this from release tracking list.