1454579 - mouse wheel scrolls horizontally even when it can scroll vertically

Status: VERIFIED DUPLICATE of bug 1455007

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

Description

[lilydjwg]

Attachment: test.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180416220315

Steps to reproduce:

Visit a page of long text so I will scroll down to read.
And there is a code block which has horizontal scrollbars. (See attached test page.)
Continue to scroll down when the mouse cursor is on the code block.


Actual results:

The code block scrolls horizontally. The page content doesn't scroll down.


Expected results:

Firefox should do what I let it do: scroll down, not right!

The page content should scroll down even there are blocks under the cursor that can scroll right.

mozregression tells me this:

 3:44.37 INFO: Last good revision: dc42a9d9c636524e26406d20ace0cabae459880c
 3:44.37 INFO: First bad revision: 6cbf314341e7d9fbc4f7ff4dcbe1c60beace0715
 3:44.37 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dc42a9d9c636524e26406d20ace0cabae459880c&tochange=6cbf314341e7d9fbc4f7ff4dcbe1c60beace0715

Comment 1

[lilydjwg]

The pushlog refers to bug 1358017, which seems to deal with vertical text. In my case there are no vertical text or any indication of that.

Comment 2

[Ed Morley [:emorley]]

I can reproduce using the attached testcase.

I've also been hitting this multiple times a day when using GitHub.

Alternate STR:
1) Visit https://github.com/jantimon/html-webpack-plugin/blob/75eef8876bb54e80f9493a544759493ed385d7e0/index.js
2) Hover the mouse cursor over the main code block
3) Scroll with the mouse wheel

Expected:
Scrolls up and down.

Actual:
The code block scrolls side to side.

This is using Windows 10 x64 1709, with yesterday's Nightly (and any in the few days before that), and logitech mouse drivers installed.

Comment 3

[張俊芝(ZHANG Junzhi)]

The title for bug 1358017 is actually incorrect, and sorry to forget to change the title, the solution for the bug was changed in the following comments, please see the messages from comment 1 to comment 16. Actually if a target has only one scrollable direction, then any wheel scroll(no matter it's vertical or horizontal) is for that direction.

It can be turned on/off through the pref mousewheel.autodir.enabled.

Comment 4

[張俊芝(ZHANG Junzhi)]

The title for bug 1358017 is actually incorrect, and sorry to forget to change the title, the solution for the bug was changed in the following comments, please see the comments from https://bugzilla.mozilla.org/show_bug.cgi?id=1358017#c1 to https://bugzilla.mozilla.org/show_bug.cgi?id=1358017#c16. Actually if a target has only one scrollable direction, then any wheel scroll(no matter it's vertical or horizontal) is for that direction.

It can be turned on/off through the pref mousewheel.autodir.enabled.

Currently, it's an experimental behaviour, so it's only enabled in nightly build and beta version by default.

So it's not a regression, I'll change the title of the bug.

Comment 5

[Ed Morley [:emorley]]

Ah ok - thank you for the clarification.

I'm presuming the new feature is intended to help with pages where there is zero scroll up and down, such that users whose mouse/touchpad only supports vertical scrolling can still use it to scroll side to side? 

If so, was it intended to also cover the cases where there is also vertical scrolling? (eg the github page linked above). Since this case seems quite undesirable to change.

Comment 6

[張俊芝(ZHANG Junzhi)]

The purpose of the idea from the comments is that it provides convinent horizontal scrolling for people who don't have a horizotnal mouse wheel. So, with autodir, they no longer have to move the cursor to the scrollbar to drag it, just scrolling the vertical wheel does this. From the comments, there are thoughts favoring the idea.

But thoughts vary from person to person. As you said, some people may find it undesirable, so it's just an experimental behaviour which may be changed in the future(We can add another pref item which makes it only available on vertical writing pages).

Comment 7

[張俊芝(ZHANG Junzhi)]

(In reply to Ed Morley [:emorley] from comment #5)
> Ah ok - thank you for the clarification.
> 
> I'm presuming the new feature is intended to help with pages where there is
> zero scroll up and down, such that users whose mouse/touchpad only supports
> vertical scrolling can still use it to scroll side to side? 

Exactly.

> 
> If so, was it intended to also cover the cases where there is also vertical
> scrolling? (eg the github page linked above). Since this case seems quite
> undesirable to change.

Autodir scrolling will apply if *the currently scrolling target*(NOT the whole page) has only one scrollable direction.

So, yes, from the view of bug 1358017, it's expected to scroll horizontally on the github page if the cursor is hovering over the inner <div>.

Comment 8

[張俊芝(ZHANG Junzhi)]

Just as a note:

The direction of a continuous scrolling is transactional, in other words, if you scrolled the vertical wheel *quickly* on a page, then you wouldn't see the scrolling direction suddenly be changed by auto-dir even if the cursor entered into a target which is only horizontally scrollable.

Only if the previous scrolling has ended for a while after the cursor is hovering over this target, then the next scrolling will be affected by auto-dir.

Comment 9

[Ed Morley [:emorley]]

Ah I hadn't realised that. I think the problem with the GitHub use-case is that typically the <div> with the horizontal scrollbar falls right in the area where my mouse cursor is on pageload, thereby meaning the first scroll is always going to be horizontal.

Comment 10

[lilydjwg]

The day I reported this issue, I've encountered this issue three times. Two with GitHub and one with a documentation page (so I know that this is not a GitHub update). There are often code blocks that have long lines which aren't that important for many readers to read carefully. And when I read documentation, I often stop to think or try some code, then I just want to continue. I didn't move your mouse so I presume it will continue to scroll down. But sometimes I'm unlucky.

Comment 11

[張俊芝(ZHANG Junzhi)]

(In reply to lilydjwg from comment #10)
> The day I reported this issue, I've encountered this issue three times. Two
> with GitHub and one with a documentation page (so I know that this is not a
> GitHub update). There are often code blocks that have long lines which
> aren't that important for many readers to read carefully. And when I read
> documentation, I often stop to think or try some code, then I just want to
> continue. I didn't move your mouse so I presume it will continue to scroll
> down. But sometimes I'm unlucky.

Hmm, what you pointed out are realistic cases on pages with code blocks, which exist dominantly on pages relating to programming, and it does violate the user's current habit.

Luckily, this has been written as an experimental behaviour only on nightly and beta, so we can have some time to get feedbacks from the users as to how to improve the behaviour.

Comment 13

[Pascal Chevrel:pascalc]

(In reply to Zhang Junzhi from comment #11)
> Hmm, what you pointed out are realistic cases on pages with code blocks,
> which exist dominantly on pages relating to programming, and it does violate
> the user's current habit.
> 
> Luckily, this has been written as an experimental behaviour only on nightly
> and beta, so we can have some time to get feedbacks from the users as to how
> to improve the behaviour.

I am also getting end user reports from Nightly users that scrolling is broken that point to the same regression range:
https://twitter.com/niborst/status/986060406618648577

Zhang, Github and TweetDeck are high visibility sites especially for our Nightly and Dev Edition populations.
We don't want Github to be broken for our Dev Edition population, given that the merge to beta is next week and unless you have an immediate fix, I will ask for your patch to be backed out.

Comment 14

[張俊芝(ZHANG Junzhi)]

(In reply to Pascal Chevrel:pascalc from comment #13)
> (In reply to Zhang Junzhi from comment #11)
> > Hmm, what you pointed out are realistic cases on pages with code blocks,
> > which exist dominantly on pages relating to programming, and it does violate
> > the user's current habit.
> > 
> > Luckily, this has been written as an experimental behaviour only on nightly
> > and beta, so we can have some time to get feedbacks from the users as to how
> > to improve the behaviour.
> 
> I am also getting end user reports from Nightly users that scrolling is
> broken that point to the same regression range:
> https://twitter.com/niborst/status/986060406618648577
> 
> Zhang, Github and TweetDeck are high visibility sites especially for our
> Nightly and Dev Edition populations.
> We don't want Github to be broken for our Dev Edition population, given that
> the merge to beta is next week and unless you have an immediate fix, I will
> ask for your patch to be backed out.

The quick solution is adding a new pref item which disable the autodir feature on horizontal text pages, and making the new pref defaults to true, and it can be done in a week.

Comment 15

[張俊芝(ZHANG Junzhi)]

The new patch is under test, will be uploaded once tested.

Comment 16

[張俊芝(ZHANG Junzhi)]

It should be fixed in bug 1455007, please re-test it.

If the issue no longer exists, then we can close it.

Comment 17

[Ed Morley [:emorley]]

Thank you - I'll test once the next Nightly is released.

Btw meant to say my mouse does support horizontal scrolling. Was this feature still meant to be activated in this case?

Comment 18

[張俊芝(ZHANG Junzhi)]

(In reply to Ed Morley [:emorley] from comment #17)
> Thank you - I'll test once the next Nightly is released.
> 
> Btw meant to say my mouse does support horizontal scrolling. Was this
> feature still meant to be activated in this case?

Unfortunately, yes. because we have no way to know whether the user's pointing device supports horizontal scrolling or not.

I am thinking about a refined UX solution, and will propose it when I've already done it.

If you're interested in helping out, I can also needinfo you.

Comment 19

[張俊芝(ZHANG Junzhi)]

Can anybody reproduce the issue?

Comment 20

[Ed Morley [:emorley]]

Resolved for me now, thank you

Comment 21

[張俊芝(ZHANG Junzhi)]

Thank you for the feedback.

I think we will be safe to mark the bug resolved if no one can reproduce this issue in Firefox newer than bug 1455007 in one day.

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Fixed by bug 1455007.

Comment 23

[Botond Ballo [:botond]]

I noticed this, and I actually liked it, since it allowed to scroll horizontally scrollable code samples with my mousewheel without having to perform the more involved gesture of dragging its scrollbar.

Comment 24

[張俊芝(ZHANG Junzhi)]

(In reply to Botond Ballo [:botond] from comment #23)
> I noticed this, and I actually liked it, since it allowed to scroll
> horizontally scrollable code samples with my mousewheel without having to
> perform the more involved gesture of dragging its scrollbar.

It still can be enabled by setting mousewheel.autodir.enabled to true.

We might need to find a solution that satifies the maximum population. I am going to propose on dev mailing lists to hear from UX team on this.

Comment 25

[Ed Morley [:emorley]]

(In reply to Botond Ballo [:botond] from comment #23)
> I noticed this, and I actually liked it, since it allowed to scroll
> horizontally scrollable code samples with my mousewheel without having to
> perform the more involved gesture of dragging its scrollbar.

If your mouse/trackpad doesn't support horizontal scrolling, the other option (aside from flipping the pref back) is to hold down shift when scrolling vertically, which converts it into horizontal scroll.

Comment 26

[張俊芝(ZHANG Junzhi)]

As of Firefox 58, [Shift + Vertical wheel scroll] triggers a horizontalized scroll, but it's better than before, but still sub-optimal. Even in a pointing device with native support of horizontal scrolling, horizontal scrolling is still not as convinent as vertical scrolling.

I submitted a proposal on csswg-drafts Github https://github.com/w3c/csswg-drafts/issues/2602, if anyone is interested in the discussion, please comment on it. Thanks.

Comment 27

[張俊芝(ZHANG Junzhi)]

s/as of/as from