Notification container scrolling in native-scrolling UtilityTray causes tray to fling up due to nested scroll container momentum.



Firefox OS
Gaia::System::Status bar, Utility tray, Notification
2 years ago
2 years ago


(Reporter: mcav, Assigned: mcav)



Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.5+, b2g-v2.5 verified)


(Whiteboard: [systemsfe])


(1 attachment)



2 years ago
Following the new native-scrolling Utility Tray from bug 1178162, we now have the following problem as described originally by Etienne:

"When you have a lot of notifications, the #notifcations-container is scrollable, so we have a nested APZ scrolling area inside the #utility-tray-motion. And when we reach the end of the nested scrolling area, gecko starts scrolling the parent one.

The result is that if you have tons of notification and you want to flick to go to the bottom of the list, we close the utility tray :/

We could play with dynamically setting the overflow-y of motion to "hidden" but it's pretty costly so I'm not sure it's viable..."

Known options/workarounds:

- try to toggle overflow-y on and off for the parent container
- platform adds something like the opposite of moz-scrollgrab
- implement non-native scrolling for the nested container
[Blocking Requested - why for this release]: Functional regression. A user may close the utility tray whereas he wanted to perform another action.

After updating my dogfood device to [1], I manage to close the utility while dismissing the 2nd or 3rd notification I had in the list. 

[1] Build ID               20151002110438
Gaia Revision          9a682cb7bc8b7fde624a9b2b3c2d64415a08b04b
Gaia Date              2015-10-02 03:13:40
Gecko Revision
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150619.224059
Firmware Date          Fri Jun 19 22:41:08 UTC 2015
Bootloader             s1
blocking-b2g: --- → 2.5?
Keywords: regression
blocking-b2g: 2.5? → 2.5+
Whiteboard: [systemsfe]
Priority: -- → P3
Shot in the dark. And it might be exploiting a gecko bug.

But it looks like a scrollable container with css snapping will not "propagate" the scroll to a parent container with scroll snapping.

Haven't tried. But might be worth it to add a dummy container around the notifications with some snapping on just to see.
Marcus, can you investigate Etienne's suggestion from comment 2? If that doesn't work, let's unblock this for 2.5 because the impact/effort ratio is potentially low here.
Flags: needinfo?(m)


2 years ago
Assignee: nobody → m
Flags: needinfo?(m)

Comment 4

2 years ago
Created attachment 8674534 [details] [review]
[gaia] mcav:utility-tray-nest > mozilla-b2g:master


2 years ago
Attachment #8674534 - Flags: feedback?

Comment 5

2 years ago
Comment on attachment 8674534 [details] [review]
[gaia] mcav:utility-tray-nest > mozilla-b2g:master

I wasn't able to get scroll-snapping itself to do anything useful, but your idea *did* provide a good similar solution, based on this: Scroll momentum does not propagate through an "overflow: scroll" element if the element's content does not actually overflow.

So, by inserting an element in between, as you suggested, we can conditionally interrupt the nested scroll momentum.

This patch implements the following UX:

- If the notifications are scrollable, dragging on the notifications *only* scrolls the notifications, and does not propagate to the tray.

- If there are not enough notifications to be scrollable, dragging on the notifications drags the tray.

Patch notes:

- This patch does *not* attempt to detect that the notifications container has scrolled to the bottom. In theory, we could allow the scroll to propagate in this case; however, I attempted this, and was left with unwanted "interrupted-scroll"-type glitches.

- We only want the scroll-intercepting element to have "overflow: scroll" when the notifications container is actively overflowing; otherwise, if you had only one notification, dragging on the notification wouldn't scroll the tray itself.

I'll add/update tests following your feedback.
Attachment #8674534 - Flags: feedback? → feedback?(etienne)
Comment on attachment 8674534 [details] [review]
[gaia] mcav:utility-tray-nest > mozilla-b2g:master

Sweet and simple and the experience is much improved.
And yep, we should be able to cover the |recalculateNotificationsContainerHeight| stuff pretty extensively with unit tests.
Attachment #8674534 - Flags: feedback?(etienne) → feedback+

Comment 7

2 years ago
Comment on attachment 8674534 [details] [review]
[gaia] mcav:utility-tray-nest > mozilla-b2g:master

Unit tests added.
Attachment #8674534 - Flags: review?(etienne)
Attachment #8674534 - Flags: review?(etienne) → review+

Comment 8

2 years ago
Last Resolved: 2 years ago
Resolution: --- → FIXED


2 years ago
Duplicate of this bug: 1214910

Comment 10

2 years ago
Today I've noted that this issue is again present.

Because I was playing with an Utility Tray addon I'm making I just reflashed everything again.

flame v180_4 + shallow flash from ftp latest flame_kk (8 november)

Also tryed the 2.6 simulator for linux ( and also it's present.

Comment 11

2 years ago
Fixed in today's update. Sorry for the noise.
According to Description of bug1233356, this issue has been fixed on v2.5.
status-b2g-v2.5: --- → verified


2 years ago
Duplicate of this bug: 1233356
You need to log in before you can comment on or make changes to this bug.