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)
Firefox OS Graveyard
Gaia::System::Status bar, Utility tray, Notification
ARM
Gonk (Firefox OS)
Tracking
(blocking-b2g:2.5+, 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
Comment 1•9 years ago
|
||
[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
Updated•9 years ago
|
blocking-b2g: 2.5? → 2.5+
Whiteboard: [systemsfe]
Updated•9 years ago
|
Priority: -- → P3
Comment 2•9 years ago
|
||
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.
Comment 3•9 years ago
|
||
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 | ||
Updated•9 years ago
|
Assignee: nobody → m
Flags: needinfo?(m)
Comment 4•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8674534 -
Flags: feedback?
Assignee | ||
Comment 5•9 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 6•9 years ago
|
||
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+
Assignee | ||
Comment 7•9 years ago
|
||
Comment on attachment 8674534 [details] [review] [gaia] mcav:utility-tray-nest > mozilla-b2g:master Unit tests added.
Attachment #8674534 -
Flags: review?(etienne)
Updated•9 years ago
|
Attachment #8674534 -
Flags: review?(etienne) → review+
Assignee | ||
Comment 8•9 years ago
|
||
master: https://github.com/mozilla-b2g/gaia/commit/a87f947366c2e044bd6336e1982419ac45378969
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 10•9 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 (https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.latest.simulator/gecko.v1.mozilla-central.latest.simulator.opt) and also it's present.
Comment 11•9 years ago
|
||
Fixed in today's update. Sorry for the noise.
Comment 12•8 years ago
|
||
According to Description of bug1233356, this issue has been fixed on v2.5.
status-b2g-v2.5:
--- → verified
You need to log in
before you can comment on or make changes to this bug.
Description
•