943034 - DOM_DELTA_LINE measurements are unpredictable

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[kungfuflip]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.71 (KHTML, like Gecko) Version/6.1 Safari/537.71

Steps to reproduce:

I want a delta value measured in pixels from the `wheel` event. In my environment (Mac/traditional mouse), the `deltaMode` of wheel events is set to DOM_DELTA_LINE, so I need to convert from lines to pixels. I created a fiddle to measure how many pixels are scrolled per line:
http://jsfiddle.net/neonsilk/Zd7yB/3/


Actual results:

The ratio between lines and pixels is not consistent between `wheel` events, even when smooth scrolling is disabled, so I'm unable to compute a pixel value from a given line value.


Expected results:

The measurement of a line should be consistent and predictable. Otherwise, it isn't meaningful.

Additionally, it's suggested elsewhere the the measurement of a line is dependent on font-size (https://bugzilla.mozilla.org/show_bug.cgi?id=934285#c5), but I could only affect scroll behavior by changing the default font size setting. And as far as I know, the default font size is inaccessible to developers (i.e. through JS) when it's overridden.

Comment 1

[Olli Pettay [:smaug][[e-mail]] (vacation-ish -> Aug 1)]

Line depends on the layout of the page.

Comment 2

[kungfuflip]

(In reply to Olli Pettay [:smaug] from comment #1)
> Line depends on the layout of the page.

Can you elaborate what you mean by "the layout of the page"?

The only way I'm able to change the behavior is by changing Firefox's default font size. The ratios between lines and pixels seem to be distributed around the selected size.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Using scrollable element's font-size.
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp?rev=e9c7bf84fcfb#2574
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp?rev=e9c7bf84fcfb#2648

Indeed, you cannot compute exactly actual font size of the scrollable element, but DOM_DELTA_LINE is losless information of native event. It doesn't make sense to tell lossy native event information to web apps.

What scenario do you have trouble about the non-DOM_DELTA_PIXEL? "wheel" events do NOT represent that scroll will occur. For example, if a modifier key is pressed, the behavior depends on user settings. Any scrollable element may not be scrolled by the modified wheel event. Another example, even if user sets the pref of acceleration of mouse wheel scroll, the delta value is NOT accelerated scroll amount. Additionally, scroll may be occurred with other operations such as arrow keys, Page Up/Down keys, dragging scrollbar and swiping on touchscreen of mobile device. So, you can NOT use wheel event as a "pre-scroll" event.

"wheel" event should be used for creating custom scrollable element which don't have scrollbars generated by browsers. Or, something non-scrollable behavior, e.g., on games. In these cases, web developers *can* assume proper font-size for DOM_DELTA_LINE and proper page size for DOM_DELTA_PAGE.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: Somebody claims that always using DOM_DELTA_PIXEL on Blink/WebKit isn't good behavior.
http://code.google.com/p/chromium/issues/detail?id=227454#c22

Comment 5

[kungfuflip]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #3)
> Using scrollable element's font-size.
> http://mxr.mozilla.org/mozilla-central/source/layout/generic/
> nsGfxScrollFrame.cpp?rev=e9c7bf84fcfb#2574
> http://mxr.mozilla.org/mozilla-central/source/layout/generic/
> nsGfxScrollFrame.cpp?rev=e9c7bf84fcfb#2648
> 
> Indeed, you cannot compute exactly actual font size of the scrollable
> element, but DOM_DELTA_LINE is losless information of native event. It
> doesn't make sense to tell lossy native event information to web apps.
> 
> What scenario do you have trouble about the non-DOM_DELTA_PIXEL? "wheel"
> events do NOT represent that scroll will occur. For example, if a modifier
> key is pressed, the behavior depends on user settings. Any scrollable
> element may not be scrolled by the modified wheel event. Another example,
> even if user sets the pref of acceleration of mouse wheel scroll, the delta
> value is NOT accelerated scroll amount. Additionally, scroll may be occurred
> with other operations such as arrow keys, Page Up/Down keys, dragging
> scrollbar and swiping on touchscreen of mobile device. So, you can NOT use
> wheel event as a "pre-scroll" event.
> 
> "wheel" event should be used for creating custom scrollable element which
> don't have scrollbars generated by browsers. Or, something non-scrollable
> behavior, e.g., on games. In these cases, web developers *can* assume proper
> font-size for DOM_DELTA_LINE and proper page size for DOM_DELTA_PAGE.

I'm trying to emulate scroll behavior on an element that isn't scrollable, and I want the emulated behavior to match the behavior of elements that are scrollable.

I appreciate the ideal of providing a lossless native measurement, but it's not useful in practice because Firefox doesn't respect its value (i.e. its interpretation is lossy). Firefox converts a DOM_DELTA_LINE to pixels differently from one wheel event to the next. And there's no means for a developer to reproduce the conversion – it's a black box.

We also can't assume a font size, since the conversion is affected by the user's default font size setting, even if that setting is overridden by the page.

If the delta values are measured in lines, then I'd expect that they would take into account the height of a line.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to kungfuflip from comment #5)
> I'm trying to emulate scroll behavior on an element that isn't scrollable,
> and I want the emulated behavior to match the behavior of elements that are
> scrollable.

First of all, if you want to emulate it perfectly, it's impossible. Scrolling of browser is just a default action of wheel event. I.e., wheel event information doesn't need to exactly match to default action result.

And the wheel event target is decided from mouse cursor position, but scroll target of default action doesn't so at least on Gecko.

> I appreciate the ideal of providing a lossless native measurement, but it's
> not useful in practice because Firefox doesn't respect its value (i.e. its
> interpretation is lossy).

As I said, the value doesn't a notify of scroll amount. If you need such information, you should suggest a new event such as "beforescroll" to www-dom of W3C.

> Firefox converts a DOM_DELTA_LINE to pixels
> differently from one wheel event to the next. And there's no means for a
> developer to reproduce the conversion – it's a black box.

Yes, it's black box because default action result isn't still decided at any events handled.

> We also can't assume a font size, since the conversion is affected by the
> user's default font size setting, even if that setting is overridden by the
> page.

Why? The element is what your application own. So, your application can decide proper font-size of the element.

> If the delta values are measured in lines, then I'd expect that they would
> take into account the height of a line.

It's an interesting argument. However, if we change the scroll amount now, some users may be confused and complain about it. So, we won't change our scroll amount except there is a huge merit.

Comment 7

[kungfuflip]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> First of all, if you want to emulate it perfectly, it's impossible.
> Scrolling of browser is just a default action of wheel event. I.e., wheel
> event information doesn't need to exactly match to default action result.

When the deltaMode is DOM_DELTA_PIXEL (when I switch to using a trackpad instead of a mouse), the behavior is exactly as I expect: the deltas correspond with Firefox's behavior, and my non-scrollable element scrolls just like a scrollable element.


> As I said, the value doesn't a notify of scroll amount. If you need such
> information, you should suggest a new event such as "beforescroll" to
> www-dom of W3C.

DOM_DELTA_PIXEL measurements do correspond to the amount scrolled, which can be tested using the fiddle in the initial report.


> > We also can't assume a font size, since the conversion is affected by the
> > user's default font size setting, even if that setting is overridden by the
> > page.
> 
> Why? The element is what your application own. So, your application can
> decide proper font-size of the element.

I stand corrected! The font-size CSS rule does affect behavior (although not line-height, strangely). This fiddle demonstrates: http://jsfiddle.net/neonsilk/Zd7yB/4/


> It's an interesting argument. However, if we change the scroll amount now,
> some users may be confused and complain about it. So, we won't change our
> scroll amount except there is a huge merit.

You hit the nail on the head: if the wheel event doesn't communicate Firefox's behavior, then a poor user experience is inevitable, since custom applications will necessarily behave unexpectedly (i.e. too fast or too slow), since we aren't given access to the actual delta measurements.

I don't think the scroll amount needs be changed. Either the number of DOM_DELTA_LINES should be adjusted to reflect the actual behavior, or Firefox should always use DOM_DELTA_PIXEL, like Chrome 31 and the Safari nightly.

Comment 8

[kungfuflip]

Also it's worth noting that, despite being "lossless information of native event", no other native Mac app that I've tested scrolls by line (or has scrolling behavior affected by font size), including Safari.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to kungfuflip from comment #7)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> > First of all, if you want to emulate it perfectly, it's impossible.
> > Scrolling of browser is just a default action of wheel event. I.e., wheel
> > event information doesn't need to exactly match to default action result.
> 
> When the deltaMode is DOM_DELTA_PIXEL (when I switch to using a trackpad
> instead of a mouse), the behavior is exactly as I expect: the deltas
> correspond with Firefox's behavior, and my non-scrollable element scrolls
> just like a scrollable element.
> 
> 
> > As I said, the value doesn't a notify of scroll amount. If you need such
> > information, you should suggest a new event such as "beforescroll" to
> > www-dom of W3C.
> 
> DOM_DELTA_PIXEL measurements do correspond to the amount scrolled, which can
> be tested using the fiddle in the initial report.

No, it depends on user's setting. If user enables scroll speed accelerator, the accelerator affects only default action speed, not delta values of wheel event.

Additionally, even if the wheel event's default action causes zoom or navigating the history, you cannot know the fact from wheel event's any information. How do you decide if the wheel event is expected as scroll? It's impossible.

> > > We also can't assume a font size, since the conversion is affected by the
> > > user's default font size setting, even if that setting is overridden by the
> > > page.
> > 
> > Why? The element is what your application own. So, your application can
> > decide proper font-size of the element.
> 
> I stand corrected! The font-size CSS rule does affect behavior (although not
> line-height, strangely). This fiddle demonstrates:
> http://jsfiddle.net/neonsilk/Zd7yB/4/

I meant that your application can control the scrolling speed for line/page (and also pixel!) scroll *like native applications*. Even if native scroll amount is 3 lines, it may not be proper speed on some applications (including both native and web apps).

> > It's an interesting argument. However, if we change the scroll amount now,
> > some users may be confused and complain about it. So, we won't change our
> > scroll amount except there is a huge merit.
> 
> You hit the nail on the head: if the wheel event doesn't communicate
> Firefox's behavior, then a poor user experience is inevitable, since custom
> applications will necessarily behave unexpectedly (i.e. too fast or too
> slow), since we aren't given access to the actual delta measurements.

Your claim is correct. But it's not realistic. How do you get the scroll amount of other scroll operation such as: arrow keys, page up/down keys, home/end keys, click on scrollbar's arrow button and click on scrollbar except thumb? We struggle with such native behavior at implementing XUL, it's very tough, and I strongly believe that it's impossible to expose them to web apps.

If web apps provides native behavior to their users, web apps shouldn't create custom scroll area. It's anyway inaccessible. E.g., a11y tools cannot know where are scrollable.

> I don't think the scroll amount needs be changed. Either the number of
> DOM_DELTA_LINES should be adjusted to reflect the actual behavior, or
> Firefox should always use DOM_DELTA_PIXEL, like Chrome 31 and the Safari
> nightly.

See Chromium issue's comment mentioned in comment 4. He or she claims Firefox's behavior is better. I believe so.

(In reply to kungfuflip from comment #8)
> Also it's worth noting that, despite being "lossless information of native
> event", no other native Mac app that I've tested scrolls by line (or has
> scrolling behavior affected by font size), including Safari.

I already said, your application can decide the scroll amount even if the wheel event is lines or pages. Other native applications also do so with receiving same event.


I'm marking this bug INVA because:

* wheel event isn't an event which reports default action's scroll amount.
* If web apps need/want to provide exact same behavior as native applications, they should NOT create custom scrollable element.
* If web apps need exact scroll amount for pseudo scrollable element, there should be new API and event for telling when and how much scroll in the custom element. However, here is not a good location for discussing it. It's really a scope of HTML and/or DOM Events. So, this should be discussed in W3C's ML.