Scroll step in Firefox is too small

[akhilman]

Describe the bug
Scrolling step and speed are too small. The area scroll by only 3 pixels per click of the scroll wheel.
WebKit and Blink based browsers scroll 60 pixels in one click.

To Reproduce
Steps to reproduce the behavior:

1. Open https://emilk.github.io/egui/index.html#demo in Firefox.
2. Scroll any scroll area with mouse wheel.
3. The area scroll by 3 pixel per click.

Expected behavior
The area should scroll about 60 pixels in single click.

Screenshots
https://user-images.githubusercontent.com/180812/106979999-03b4d180-6792-11eb-8b99-04938d175cfe.mp4

Desktop (please complete the following information):

• OS: Debian Sid
• Browser: Firefox
• Version: 84.0.2 (64-bit)

[follower]

TL;DR: Probably need to account for the "scale"/units indicated by delta_mode when using delta_* scroll wheel values.

Context

I also observed this behaviour in Firefox on ElementaryOS on a laptop with a trackpad.

Relevant code

From a brief investigation it appears this may be the relevant code:

egui/egui_web/src/lib.rs

Lines 809 to 820 in 0f33bc7

	let event_name = "wheel";
	let runner_ref = runner_ref.clone();
	let closure = Closure::wrap(Box::new(move |event: web_sys::WheelEvent| {
	let mut runner_lock = runner_ref.0.lock();
	runner_lock.input.raw.scroll_delta.x -= event.delta_x() as f32;
	runner_lock.input.raw.scroll_delta.y -= event.delta_y() as f32;
	runner_lock.needs_repaint.set_true();
	event.stop_propagation();
	event.prevent_default();
	}) as Box<dyn FnMut(_)>);
	canvas.add_event_listener_with_callback(event_name, closure.as_ref().unchecked_ref())?;
	closure.forget();

Specifically, the code that appears to read the delta change per axis from a WheelEvent:

egui/egui_web/src/lib.rs

Lines 813 to 814 in 0f33bc7

	runner_lock.input.raw.scroll_delta.x -= event.delta_x() as f32;
	runner_lock.input.raw.scroll_delta.y -= event.delta_y() as f32;

Underlying cause?

The MDN WheelEvent docs mention the delta* (a.k.a delta_*) values are:

a double representing the [axis] scroll amount.

But the docs also mention a deltaMode (a.k.a delta_mode) which is:

an unsigned long representing the unit of the delta* values' scroll amount

with valid values for:

• DOM_DELTA_PIXEL (0x00)
• DOM_DELTA_LINE (0x01)
• DOM_DELTA_PAGE (0x02)

Thus, the underlying cause of the issue seems like it might be not taking the delta_mode value into account when performing calculations with the delta_* values.

I suspect the exact behaviour observed is probably dependent on the specific combination of:

1. Browser.
2. Input device. (e.g. mouse vs trackpad)
3. OS configuration.

(Although the browsers may themselves handle some of the variance.)

Path to a solution

It seems like a solution to this issue would require:

1. A design decision re: how egui handles scroll delta event data from backends. e.g. "backend must convert delta into egui units". (Maybe this is already specified somewhere already? I've not yet looked.)
2. Patch to egui_web/src/lib.rs to account for the impact of delta_mode on the delta_* value.

Additional details

• WheelEvent seems to originate from web-sys here:

  egui/egui_web/Cargo.toml

  Line 68 in e5233d2

  "WheelEvent",

• web_sys docs for WheelEvent.delta_mode method:

  • https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.WheelEvent.html#method.delta_mode

• RawInput documents scroll_delta units as "points (logical pixels)":

  egui/egui/src/data/input.rs

  Lines 9 to 13 in b61db03

  	/// All coordinates are in points (logical pixels) with origin (0, 0) in the top left corner.
  	#[derive(Clone, Debug)]
  	pub struct RawInput {
  	/// How many points (logical pixels) the user scrolled
  	pub scroll_delta: Vec2,

• InputState documents scroll_delta as "How many pixels":

  egui/egui/src/input_state.rs

  Lines 22 to 23 in b61db03

  	/// How many pixels the user scrolled.
  	pub scroll_delta: Vec2,

• egui_glium backend handles pixel/point vs line delta values here:

  egui/egui_glium/src/lib.rs

  Lines 156 to 167 in 2470261

  	WindowEvent::MouseWheel { delta, .. } => {
  	match delta {
  	glutin::event::MouseScrollDelta::LineDelta(x, y) => {
  	let line_height = 24.0; // TODO
  	input_state.raw.scroll_delta = vec2(x, y) * line_height;
  	}
  	glutin::event::MouseScrollDelta::PixelDelta(delta) => {
  	// Actually point delta
  	input_state.raw.scroll_delta = vec2(delta.x as f32, delta.y as f32);
  	}
  	}
  	}

• Related links:

  • https://stackoverflow.com/questions/20110224/what-is-the-height-of-a-line-in-a-wheel-event-deltamode-dom-delta-line

    • (includes link to a jsfiddle that displays related values when text area is scrolled via wheel/pad: https://jsfiddle.net/neonsilk/Zd7yB/1/)

  • https://stackoverflow.com/questions/5527601/normalizing-mousewheel-speed-across-browsers

• Related bugs:

  • Mouse scroll delta is not scaled properly emscripten-core/emscripten#6283

  • Normalizing MouseWheel in different browsers/platforms goxjs/glfw#10

  • "The value of deltaX and deltaY of WheelEvent should be in CSS pixels if its deltaMode is DOM_DELTA_PIXEL"

• Have a sense of deja vu about this because I seem to recall Qt (& maybe Godot also?) had a similar issue at one point particularly in relation to Mac trackpads.

• Also, not sure if relevant with Canvas but the MDN docs also warn "the delta* values in the wheel event [don't] necessarily reflect the content's scrolling direction".

[follower]

Approaches used by other Rust projects to handle scroll wheel delta issue, in no particular order (click to view):

• (Oh, I forgot the code previews aren't rendered for other projects, so will need to view via the permalinks.)

• https://github.com/sebcrozet/kiss3d/blob/d39bbf5b2374bf2062386a7047274c759f1902d5/src/window/webgl_canvas.rs#L368-L391

• https://github.com/rust-windowing/winit/blob/b9f3d333e41464457f6e42640793bf88b9563727/src/platform_impl/web/web_sys/event.rs#L43-L55

• https://github.com/libcala/human/blob/d6b2bc938e3ab6dae2d1bcd449b3db0be6a77f86/src/web.rs#L250-L266

  • https://github.com/libcala/human/blob/d6b2bc938e3ab6dae2d1bcd449b3db0be6a77f86/src/web.rs#L554-L560

• https://github.com/kuviman/geng/blob/bdeda19f927df521157a8bacdcfb2aa236784bdf/src/window/events/web.rs#L143-L158

• https://github.com/linebender/druid/blob/de5f88ad946d052e377cffa8347ad2cf2c3662dd/druid-shell/src/platform/web/window.rs#L232-L244

• https://github.com/linebender/druid/blame/de5f88ad946d052e377cffa8347ad2cf2c3662dd/druid-shell/src/platform/web/window.rs#L224-L244

• https://github.com/ruffle-rs/ruffle/blob/1990e5163994780784f79d03c09f0556262175ca/web/src/lib.rs#L691-L712

• https://github.com/dakom/awsm-renderer/blob/f7ecfa560b19577b188fc16fcdc33ee54a8204c9/crate/src/input/listeners.rs#L177-L193

• https://github.com/Elyhaka/Swaynimated/blob/034840733dfe170d79ae34d5e4cdaceb37e26694/winit/src/platform_impl/web/stdweb/event.rs#L33-L42

• https://github.com/RSSchermer/ARWA/blob/47c455b98b6f7a9bc5c6b2fc50d6b3e22c55fbe5/arwa/src/event/wheel_event.rs#L17-L36

• haileys/mixlab@2c79587

[emilk]

@follower thanks for that detailed analysis! egui does indeed expect the scroll to be in logical pixels (what egui calls "points"). As you see from the glium version I just hacked in 24.0 there as "better than nothing" solution. Any improvements are very welcome!

On my mac egui_web works well with my trackpad, but poorly with my mouse scroll wheel (which I rarely use, which is why this went unnoticed).

[trusktr]

Too many inconsistencies across browsers. Related web spec issue:

• Needs alternative WheelEvent.deltaMode, WheelEvent.delta(X|Y|Z) w3c/uievents#181