Closed Bug 1209387 Opened 9 years ago Closed 9 years ago

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

Categories

(Firefox OS Graveyard :: Gaia::System::Status bar, Utility tray, Notification, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

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

RESOLVED FIXED
blocking-b2g 2.5+
Tracking Status
b2g-v2.5 --- verified

People

(Reporter: mcav, Assigned: mcav)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(1 file)

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         https://hg.mozilla.org/mozilla-central/rev/5f16c6c2b969f70e8da10ee34853246d593af412
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)
Assignee: nobody → m
Flags: needinfo?(m)
Attachment #8674534 - Flags: feedback?
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

\o/
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 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+
master: https://github.com/mozilla-b2g/gaia/commit/a87f947366c2e044bd6336e1982419ac45378969
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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 (https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.latest.simulator/gecko.v1.mozilla-central.latest.simulator.opt) and also it's present.
Fixed in today's update. Sorry for the noise.
According to Description of bug1233356, this issue has been fixed on v2.5.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: