895499 - Mac-style overlay scrollbars should appear longer

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[Florian Bender]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130715155216

Steps to reproduce:

Click on the search link above. 


Actual results:

Scrollbars in multiple-select boxes are shown, but hidden within a quarter of a second. 


Expected results:

Scrollbars should be visible for over one second (my very unscientific measurement of a scrollbar in a Finder window shows that Mac displays the scrollbar for >1 sec, maybe ~1.5 sec).

Comment 1

[Florian Bender]

Oh, yeah, I meant the "Advanced Search" form of Bugzilla.

Comment 2

[André Reinald]

This seems related (but not identical) to bug 868659.

I guess you want the 1.5 second delay between a scrollwheel user stops scrolling and the scrollbars disappear?

For Touchpad (and magic mouse ?) users, as far as I understand, the scrollbars should stay as long as they keep the 2 fingers down.

Comment 3

[Stephen A Pohl [:spohl]]

This is as simple as tweaking eIntID_ScrollbarFadeBeginDelay:
http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsLookAndFeel.mm#365

The tougher part is to find the right value.

Comment 4

[Florian Bender]

(In reply to André Reinald from comment #2)
> This seems related (but not identical) to bug 868659.

Yes and no. This bug is also about just navigating to a site. Of course, if you mouseover an overflown subview (like the multiple-selects) and hold two fingers down (like scrolling), the scrollbars should of course appear. This bug is not about that, though. 

(In reply to Stephen Pohl [:spohl] from comment #3)
> The tougher part is to find the right value.

I'd start with at least 1000ms, maybe 1250ms? 

Maybe we want that value to be user-adjustable, at least for development and until we figure out a good value. Is that an option, or do you prefer finding a "correct" one and set it as a fixed value?

Comment 5

[Stephen A Pohl [:spohl]]

(In reply to Florian Bender from comment #4)
> do you prefer finding a "correct" one and set it as a fixed value?

This is the right thing to do.

Comment 6

[Stephen A Pohl [:spohl]]

Markus, do you recall how the original 450ms were chosen? Do you have any thoughts on what this value should be or how to measure for parity with the OS?

Comment 7

[Markus Stange [:mstange]]

Usually in these cases I make a screen recording of the behavior in a native app, step through the resulting video using the cursor keys in Quicktime, count the number of frames that a transition takes, and then divide the number by 30 (the video's frame rate).
I thought that was the way I had arrived at the 450ms, but if it doesn't match native apps then maybe I didn't do it for this number. Or the timing changed between 10.7 and 10.8, or it's different in different scenarios.

Comment 8

[Florian Bender]

I just tried to test the appearance duration. Judging by the limited information I got from that the 450ms number may be correct. 

However, there is also a fade in (which takes some time) which Firefox does not do. So either, we fade in, too (and count the 450ms after the transition completed), or just show the scrollbar longer (like ~1 sec). (I don't see a fade in when accessing the advanced search page.) 

There may be a Web-only issue: It takes some time before a widget appears when rendering a website, furthermore some widgets may be rendered while others are not yet displayed. So for the scrollbars to appear, Firefox should wait for (at least) the DOMContentLoaded event before it starts the scrollbar logic. I don't know if this is already the case.