Closed Bug 1320467 Opened 8 years ago Closed 7 years ago

Scroll amount is small in tabbar

Categories

(Firefox :: Tabbed Browser, defect, P1)

Product:
Firefox
Component:
Tabbed Browser
Version:
53 Branch
Platform:
Unspecified
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 53
Tracking Flags:
Tracking Status
firefox52 --- unaffected
firefox53 + verified

People

(Reporter: alice0775, Assigned: masayuki)

References

Details

(Keywords: platform-parity, regression, ux-jargon)

Attachments

(1 file)

Bug 1320467 <scrollbox>.lineScrollAmount should return average width or height
59 bytes, text/x-review-board-request
mstange
: review+
Details 
[Tracking Requested - why for this release]:

STR
1. Open many tabs(20-30tabs)
2. Try to scroll tabbar (Ctrl+mouse wheel)

Actual Results:
Scroll amount is small in tabbar.
The amount is only approx. 1/2 x width of tab.

Expected Results:
The amount should be approx. 3 x width of tab in default Windows
Blocks: 1316505
Version: 52 Branch → 53 Branch
The behaviour is as if smoothscroll is disabled, but only in the tab bar. Really weird.
The slowness is "by design". Current scroll speed is same as the scroll speed on macOS because new code uses scrollByPixel for all wheel events (DOM_DELTA_MODE_LINE on Windows/Linux or DOM_DELTA_MODE_PAGE on Windows).

Currently, the tabbar's font-height is used for line height at converting DOM_DELTA_MODE_LINE's delta value to pixels. Therefore, if you feel this is too slow, we need to look for better line height only for tabbar (not for <scrollbox>).

I have Microsoft's mouse and Logitech's mouse and I don't feel that both of them scroll tabbar too slow, though, because I can check each tab's text without stopping scrolling (different from the old high-speed scroll).
I do not understand by design". 
The new scroll amount is approx.1/2Tab width/1tick.
The previous scroll amount is approx.2.5Tab width/1tick.
The change is 5x slow.

@QA
Is such a big UX change by design?
Keywords: qawanted, ux-jargon
The old line scroll code assumes that line scroll wheel events come with same delta values and enough large values. This depends on old platforms' behavior such as ~WinXP and GTK2 (and very early versions of GTK3).  With supporting high resolution scrolling devices, <scrollbox>'s scroll speed was too fast (especially the scroll speed of tabbar was crazy with Logitech's mice. Turning wheel one notch causes scrolling all tabs if you open ~100 tabs).  Therefore, we needed to change the handler to respect the high resolution delta values.

On the other hand, OS X supports high resolution scroll when they try to improve their Tackpad's UX.  Therefore, <scrollbox> supported its high resolution delta values since some years ago.

The latest change is, even when deltaMode of wheel events is DOM_DELTA_MODE_LINE or DOM_DELTA_MODE_PAGE, <scrollbox> uses the path for macOS. I.e., falling back the line or page delta values to pixel delta values. So, the change the scrolling speed from too fast to slower. This is what the "slower scroll" is "by design".

On the other hand, tabbar is a special UI of <scrollbox>. For example, its aspect is extremely wider than its height and scrolls only horizontally. So, usual line height computation may not be proper for it. We might need to override the lineScrollAmount only in tabbar.

Finally, we need to be careful. If you feel current scroll speed is too slow, why Mac users haven't complained about the scroll speed for many years? Do you just compare the scroll speed with the old speed which was unexpectedly fast with some devices? I'm not saying your complaint wrong, I'm trying to say that you need to forget old unexpected scroll speed first, and then, we need to decide the better scroll speed of *tabbar* if current speed is not useful with any devices. Or if it's too slow only with some devices, we have a bug in current *<scrollbox>* implementation.
the 5x～6x slowness on Windows10 and Ubuntu16.04. (I do not know on macOS)
Keywords: pp
OS: Unspecified → All
FYI: <scrollbox> is used in popup menus. E.g., when you add a lot of bookmarks in a folder, you can scroll the popup menu contents with wheel. The scroll speed is also too slow?
(In reply to Alice0775 White from comment #5)
> the 5x～6x slowness

So, I say that comparing with old behavior doesn't make sense because the scrolling speed was unexpected in most environment. The old implementation was completely broken. It's not respected delta values except the sign, it just scrolls fixed length every wheel event.
In default settings, Windows and Linux tries to scroll 3 lines per turning wheel one notch.

However, high resolution wheel devices send wheel events with smaller delta values. For example, some devices may send 1 line * 3 wheel events, some other devices may send 0.1 lines * 30 wheel events. So, the number of wheel events depend on the devices but old <scrollbox> wheel event handler respects only the number of wheel events. (tabbar scrolled 1 tab per wheel event!)

Old handler might assume that OS sends 3 lines * 1 wheel event. If so, we need to set *tabbar*'s lineScrollAmount to 1/3 of tab width.
> high resolution wheel devices

What is it?

I am using ordinary 3 buttons USB mouse(Dell MOC5UO 1000Yen).
(In reply to Alice0775 White from comment #9)
> > high resolution wheel devices
> 
> What is it?
> 
> I am using ordinary 3 buttons USB mouse(Dell MOC5UO 1000Yen).

Some drivers of mouse wheel devices (including touch pads) split a wheel operation to a lot of WM_MOUSEWHEEL events on Windows (I'm not sure about GTK3's high resolution scroll, though). So, it depends on the device driver which you got for your pointing device. You can check if your mouse driver supports high resolution scroll with Spy++ or disabling smooth scroll of Gecko.

For example, Logitech's MX Master (MX2000) sends 0.025 lines * 120 wheel events (!) at turning wheel one notch. This behavior can do smooth scrolling if target application supports high resolution wheel events. (Due to historical reason, most Windows applications don't support high resolution wheel messages, therefore, mouse drivers use whitelist when it decides if it should use high resolution wheel events.)
I wonder, I should be back here after fixing bug 1320609. It may cause you feel scroll slower (than actual).
When disabling smooth scroll from about:preferences#advanced, the scroll amount of tabbar and menupopup is not changed.
So, my mouse does not support the high resolution wheel, right?
(In reply to Alice0775 White from comment #12)
> When disabling smooth scroll from about:preferences#advanced, the scroll
> amount of tabbar and menupopup is not changed.
> So, my mouse does not support the high resolution wheel, right?

I'm not sure about <scrollbox>. If you see same behavior in web contents, your mouse doesn't support high resolution scroll.
Yep, it is same amount on plain text document with/without smooth scroll.
My mouse doesn't support high resolution scroll.
I cannot use mouse wheel to browse my tabs anymore after this change as I value the health of my finger joints.
If what we have now is "intended" behaviour then would it be possible for some form of config option be added to control the speed?

Right now it takes ~20 seconds to scroll to the end of my fairly long list of open tabs. It uses to take considerably less than that. I'm conscious that this may be an unusual case but I doubt I'll be the only one to notice.
I meant it's intended, but still looking for better speed if fixing the other regression is not enough.
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #8)
> Old handler might assume that OS sends 3 lines * 1 wheel event. If so, we
> need to set *tabbar*'s lineScrollAmount to 1/3 of tab width.

It didn't, it was agnostic to the number of wheel events and just translated one "line" (a concept that hardly makes sense for scrollboxes that don't contain a body of text) to the width of a tab.
Priority: -- → P1
(In reply to Dão Gottwald [:dao] from comment #18)
> (In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #8)
> > Old handler might assume that OS sends 3 lines * 1 wheel event. If so, we
> > need to set *tabbar*'s lineScrollAmount to 1/3 of tab width.
> 
> It didn't, it was agnostic to the number of wheel events

WinXP and earlier and GTK2 build dispatched 3 lines wheel event. IIRC, starting WinVista, wheel events were dispatched per line.

> (a concept that hardly makes sense for scrollboxes that don't contain a body of text) to the width
> of a tab.

Yeah, I'm still investigating. However, in old code, we used scrollByIndex whose "index" is index of scrolled elements. I guess that we can use the number of visible elements and the rect for computing same speed.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
The try build (linux and win32) work for me.
Flags: needinfo?(alice0775)
(In reply to Alice0775 White from comment #21)
> The try build (linux and win32) work for me.

Ditto that. Try build is pretty much what I would have expected per previous behaviour.

Thanks for the work on this.
Flags: needinfo?(sciguyryan)
Thank you for your check!

The patch for this bug depends on the patches for bug 1316505 but they will be landed after checking on tryserver. So, the patch for this bug comes soon.
Flags: needinfo?(johan.bontekoe)
Flags: needinfo?(6lobe)
Comment on attachment 8821150 [details]
Bug 1320467 <scrollbox>.lineScrollAmount should return average width or height

https://reviewboard.mozilla.org/r/100482/#review101038
Attachment #8821150 - Flags: review?(mstange) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/5247a0fca6e2
<scrollbox>.lineScrollAmount should return average width or height r=mstange
https://hg.mozilla.org/mozilla-central/rev/5247a0fca6e2
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
I have reproduced this bug with Nightly 53.0a1 (2016-11-26) (32-bit) on WIndows 10 , 64 Bit.
This bug's fix is now verified on latest Nightly 53.0a1.

Build ID : 20161230030205
User Agent : Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0

[bugday-20161228]
QA Whiteboard: [good first verify]
I have reproduced this bug with Nightly 53.0a1 (2016-11-26) (32-bit) on Ubuntu 16.04.2 64-Bit!

This bug's fix is verified with latest Beta!

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

[bugday-20170405]
Thanks Tanvir and Maruf for testing this issue.

I also managed to reproduce the issue on Firefox 53.0a1 (2016-11-26), under Windows 10x64.
I confirm that the issue is fixed on Firefox 53.0b9 (64-bit) under Windows 10x64 and Ubuntu 16.04x64.

On Mac OS X 10.12.1, I noticed that only 1 tab at a time is scrolled. Masayuki, is this behavior expected?
Flags: needinfo?(masayuki)
(In reply to Mihai Boldan, QA [:mboldan] from comment #30)
> On Mac OS X 10.12.1, I noticed that only 1 tab at a time is scrolled.
> Masayuki, is this behavior expected?

Depending on the pointing device. On macOS, if the device supports smooth scroll, e.g., trackpad of MacBook series, Apple's mice, it scrolls the tab bar smoothly.  Otherwise, e.g., connecting not expensive mice, it may scroll tabs per tab. If you test this with third party's mice on macOS, in most cases, the behavior is latter unless it has specific utility.
Flags: needinfo?(masayuki)
Thanks for the clarification Masayuki.
The scrolled is performed tab per tab if using a normal mouse, and if using an Apple Magic Mouse, the scroll is smooth. 
Taking in consideration latest results from Mac OS X and Comment 30, I'm marking this issue Verified Fixed.
Status: RESOLVED → VERIFIED
QA Whiteboard: [good first verify]
status-firefox53: fixed → verified
Keywords: qawanted
See Also: → 1387084
Depends on: 1387701
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: