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 , I manage to close the utility while dismissing the 2nd or 3rd notification I had in the list.  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
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.
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.
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.
Comment on attachment 8674534 [details] [review] [gaia] mcav:utility-tray-nest > mozilla-b2g:master Unit tests added.
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.