Closed Bug 1074030 Opened 10 years ago Closed 10 years ago

Scrollbars flash off and on while scrolling

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(firefox33 wontfix, firefox34 fixed, firefox35 fixed, b2g-v2.0 unaffected, b2g-v2.1 fixed, b2g-v2.2 fixed)

RESOLVED FIXED
2.1 S6 (10oct)
Tracking Status
firefox33 --- wontfix
firefox34 --- fixed
firefox35 --- fixed
b2g-v2.0 --- unaffected
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(1 file)

STR:
On the homescreen, do a fling, and then do another fling (making sure to lift your finger in between)

Expected:
the scrollbar becomes visible from when you put your finger down for the first fling and doesn't disappear until the homescreen stops moving

Actual:
When you put your finger back down for the second fling, the scrollbar disappears and then re-appears.

The reason this happens is that technically putting your finger down interrupts the first fling and the APZ code sends a end-transform notification to layout. It's not until you actually start moving your finger that the APZ sends the next start-transform notification to layout, causing the scrollbar to reappear. This by itself would be ok if we had the scrollbar fade parameters set correctly, but currently they default to 0, so the scrollbar disappears instantaneously.
Not sure who should review this but it's just a pref change so it's pretty straightforward. I copied the values from what OS X desktop does [1]. This fixes the problem because now we have 450ms delay before the scrollbar starts fading out, so if you lift your finger and put it back down or whatever the scrollbar won't disappear on you.

[1] http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsLookAndFeel.mm?rev=3646cd944abe#370
Attachment #8496655 - Flags: review?(kgrandon)
Comment on attachment 8496655 [details] [diff] [review]
Set a non-instantaneous fade for the scrollbars

Review of attachment 8496655 [details] [diff] [review]:
-----------------------------------------------------------------

Seems fine to me, but I guess this would fall under the "runtime", so either Fabrice or Vivien should review.
Attachment #8496655 - Flags: review?(kgrandon)
Attachment #8496655 - Flags: review?(fabrice)
Attachment #8496655 - Flags: review?(21)
Attachment #8496655 - Flags: review?(fabrice)
Attachment #8496655 - Flags: review?(21)
Attachment #8496655 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/6779e5bc754c
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Apparently this is a regression in 2.1, because I just flashed a flame device with a 2.0-kk build and it didn't have this problem. I'm not sure what regressed it exactly, as I don't see these prefs set anywhere in b2g 2.0 code.
Comment on attachment 8496655 [details] [diff] [review]
Set a non-instantaneous fade for the scrollbars

Approval Request Comment
[Feature/regressing bug #]: unknown, but it regressed in 2.1
[User impact if declined]: scrollbars flash off and then back on when you fling while an existing fling is in progress (easy to reproduce on the homescreen, for example)
[Describe test coverage new/current, TBPL]: local manual testing
[Risks and why]: low-risk, b2g-only. Just some pref changes to adjust the scrollbar fade behavior. This patch restores the behaviour in 2.0 pretty closely as far as I can tell.
[String/UUID change made/needed]: none
Attachment #8496655 - Flags: approval-mozilla-aurora?
Attachment #8496655 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 1081072
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: