1247509 - Mouse wheel incorrectly changes zoom level in a widget on http://jsray.user2dev.com/

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160209030347
STR:
1. Set mouse option "when I rotate mouse wheel" in your OS to "scroll by 1 page"
2. Open http://jsray.user2dev.com/ in a new tab
3. Click "Render", wait until canvas is drawn
4. Hover mouse over canvas
5. Rotate mouse wheel DOWN once
6. Rotate mouse wheel UP once
7. Rotate mouse wheel UP once

Result:       
 After Step 5 canvas becomes empty.
 After Step 6 all spheres and stuff is visible in canvas.
 After Step 7 canvas becomes empty.

Expectations: 
 In Step 5 zoom level sould decrease by 1 "step" per rotation of mouse wheel
 In Step 6 zoom level sould increase by 1 "step" per rotation of mouse wheel
 In Step 7 zoom level sould increase by 1 "step" per rotation of mouse wheel

Note:
 It works fine in IE11 and Chrome so this is firefox bug

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

(In reply to arni2033 from comment #0)
>  It works fine in IE11 and Chrome so this is firefox bug
Don't know how to make that conclusion.
Especially wheel handling tends to be rather browser specific on web pages.
There are legacy mousewheel (IEism) and DOMMouseScroll and MozPixelScroll (these two are Geckoism) events and then
the standard wheel event. And depending on which event the site uses, the behavior can be different.

Comment 2

[arni2033]

(In reply to Olli Pettay [:smaug] (high review load) from comment #1)
> >  It works fine in IE11 and Chrome so this is firefox bug
> Don't know how to make that conclusion.
All such issues (bug 1171659, bug 1235541, bug 1235542, bug 1239534, bug 1247509 [this] )
happen because of 2 reasons.
1) ev.detail reports ±32768 instead of normal values (DOMMouseScroll event).
2) Tutorials Mozilla spreaded in the web do not mention ±32768:
   https://developer.mozilla.org/ru/docs/Web/Events/wheel
   Even some stuff in Firefox (see list of bugs above) fail to handle that case correctly.

NI for Olli Pettay:   Is that 32768 thing an intentional breakage or accidental?
If it's intentional, then they're not the same Core bug, but "just" numerous "tech evangelism" bugs.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

ev.detail (where ev.type is DOMMouseScroll) is supposed to return 32768 when page scrolling happens. That is what the API has been doing always.

https://developer.mozilla.org/ru/docs/Web/Events/wheel doesn't explain DOMMouseScroll, but
https://developer.mozilla.org/en-US/docs/Web/Events/DOMMouseScroll does.
It says "If the event represents scrolling up by a page, the value of detail is -32768. If the event indictes scrolling down by a page, the value is +32768."
(it just happened to be min and max of signed 16bit integer.)

Comment 4

[arni2033]

(In reply to Olli Pettay [:smaug] (vacation Feb 29 - Mar 4) from comment #3)
> ev.detail (where ev.type is DOMMouseScroll) is supposed to return 32768 when
> page scrolling happens. That is what the API has been doing always.
> 
> https://developer.mozilla.org/ru/docs/Web/Events/wheel doesn't explain DOMMouseScroll, but
> https://developer.mozilla.org/en-US/docs/Web/Events/DOMMouseScroll does.
I sure knew that. I explained it to one of your co-worker in another bug (pdfjs + on github).
Actually, I had a conversation with several people working on PDFjs, and they were really surprised

Face it, that API _Proved_ to be a trap. Nobody is aware about ±32768, even those who developed/tested/integrated PDFjs and CodeMirror. Even scrolling in tabs toolbar is affected.

Looks like only you are aware of that special value. Were you the one who developed it? Then you're the right person to ask: "Why?"  "For what?"  "What did I do to you?"
First, Mozilla makes a trap for users that use "Scroll by 1 page". Then, Mozilla wontfix/ignores issues related to that option, because "there're below 0.1% of such users". Where's the_logic?!
If it really was so low percent, why did you implement that special value in the first place?

Every site that uses DOMMouseScroll is using it wrong.
And the best part? Other browsers (85% of browser market) have provided good API, which doesn't have special values. And web devs are most likely to use their logic. So web devs either use an event that doesn't allow to distinguish 1-line scroll from 1-page scroll (remember normal browsers), or use 'wheel' event. In the first case it's completely safe to follow IE and Chrome behavior, i.e. to always return 3 as event.details. Or at least always return 3 for option "scroll by 1 page"

I do and always will treat this as a bug in Firefox. As a resolution I'd like to see X, Y or Z
 X) 1-line change from 32768 to 3 in Firefox core
 Y) An extension (or a manual to do one) that hands to web pages 3 instead of 32768 in ev.details
     (actually I tried to make one, but there were errors when web page tried to access
      nonexistent properties of event and I haven't had enough time to figure that out)
 Z) You verify that there will be no changes in that API ever, and I never ask this again. I mean,
    I wrote the full explanation. Such answer would mean that Mozilla is OK with all those breakages
    It's always good to know exact answer, so I won't wait forever until Firefox is finally fixed.

Comment 5

[arni2033]

Correction:
Every site that uses DOMMouseScroll relying on ev.details value - is using it wrong.
Sites that only rely on the fact of DOMMouseScroll event or only the sign of ev.details - are OK

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to arni2033 from comment #4)
> Face it, that API _Proved_ to be a trap.
Which is why it isn't the standard one but people should be using 'wheel' event.


> Looks like only you are aware of that special value. Were you the one who
> developed it? Then you're the right person to ask: "Why?"  "For what?" 
> "What did I do to you?"
Why so hostile attitude.

DOMMouseScroll was added very long time ago, and given that the API is deprecated ("wheel" should be used), there
isn't really need to change the API, with the risk to cause regressions.
DOMMouseScroll was added over 14 years ago in Bug 108757, and for some reason bryner and hewitt decided to use those constants there.



> First, Mozilla makes a trap for users that use "Scroll by 1 page". Then,
> Mozilla wontfix/ignores issues related to that option, because "there're
> below 0.1% of such users". Where's the_logic?!
> If it really was so low percent, why did you implement that special value in
> the first place?
The relevant bug doesn't explain why the constant was added.
But it is true that page scrolling is super rarely used, which leads to people not testing how
stuff should work when it is enabled.



> Every site that uses DOMMouseScroll is using it wrong.
> And the best part? Other browsers (85% of browser market) have provided good
> API, which doesn't have special values.
And we support wheel event too. That is the event sites should be using now, that is the standard one.



> And web devs are most likely to use
> their logic. So web devs either use an event that doesn't allow to
> distinguish 1-line scroll from 1-page scroll (remember normal browsers), or
> use 'wheel' event. In the first case it's completely safe to follow IE and
> Chrome behavior, i.e. to always return 3 as event.details. Or at least
> always return 3 for option "scroll by 1 page"
We could consider this. It does include some risk though. Some sites, intranets etc, could rely on the behavior which has been documented
for a long time and has been there since the beginning of DOMMouseScroll event.



> 
> I do and always will treat this as a bug in Firefox.
Curious, why? DOMMouseScroll is implemented only in Gecko, and the API was designed to work this way.
(but I would ok to consider changing page scrolling behavior as I said above)

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.