1141595 - [Lockscreen] Unable to scroll notification list on Lockscreen; list locks-up after 1 second

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150310_0817.txt

Description:
If you receive enough notifications they will create a scrollable list. When you reboot the device these notifications appear on the lockscreen. If you attempt to scroll that list it will scroll one or two notification's worth and then stop scrolling.

Repro Steps:
1) Update a Flame to 20150310010227
2) Create 5 or 6 notifications (screenshots, missed calls, sms)
3) Restart the device
4) Attempt to scroll the notifications on the lockscreen page

Actual:
After 1 second of scrolling the notifications can no longer be scrolled. 

Expected:
The notifications can be scrolled

Environmental Variables:
Device: Flame Master
Build ID: 20150310010227
Gaia: 2fb09da0cb9cefad9c6e40f57533fafda6d12557
Gecko: 6686aacf006f
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0


Repro frequency: 7/7

See attached: logcat video clip: http://youtu.be/5aEw8TjAYOA

Comment 1

[Joshua Mitchell (Inactive)]

This issue does not occur on 2.2 

Actual Results: Notifications can be scrolled

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150310002536
Gaia: 166491b92278dc9e648f8d49ab02d9ca00d74421
Gecko: 1cda026f8996
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Functional regression of a core feature.

Requesting a window.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20150304142439
Gaia: eff3321ab4e65da3f906688ebb55ddf1e93d9452
Gecko: 478b551b19bd
Version: 39.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20150304142742
Gaia: eff3321ab4e65da3f906688ebb55ddf1e93d9452
Gecko: 2bd95d9c12bb
Version: 39.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=478b551b19bd&tochange=2bd95d9c12bb

Caused by patches for Bug 913443.

Comment 4

[KTucker [:KTucker][Inactive 3/4/2016]]

Markus, can you take a look at this please? Looks like the landings for bug 913443 might have caused this to occur.

Comment 5

[Markus Stange [:mstange]]

I'll look at it.

Comment 6

[Markus Stange [:mstange]]

Attachment: patch

This might work. I haven't tested it yet.

Comment 7

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8576912 [details] [diff] [review]
patch

Can we assert that the items we call BuildLayer on are scroll info items only? (ie that we are only inserting empty meta data layers) And that it's layer state is active empty.

Comment 8

[Markus Stange [:mstange]]

Attachment: patch

This has turned all kinds of ugly but at least it works now. I'm using nsTArray<nsDisplayScrollInfoLayer> instead of nsDisplayList because you can't put an nsDisplayList into an nsTArray (NewLayerEntry is in an array), and my attempt to add a move constructor to nsDisplayList and have nsTArray use that through an appropriate nsTArray_CopyChooser was unsuccessful.

Comment 9

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8577548 [details] [diff] [review]
patch

>+        NewLayerEntry& layerEntry = mNewChildLayers[i];
>+        NewLayerEntry scrollInfoLayerEntry;
>+        scrollInfoLayerEntry.mLayer = scrollInfoLayer;
>+        scrollInfoLayerEntry.mAnimatedGeometryRoot =
>+          layerEntry.mAnimatedGeometryRoot;
>+        scrollInfoLayerEntry.mFixedPosFrameForLayerData =
>+          layerEntry.mFixedPosFrameForLayerData;
>+        scrollInfoLayerEntry.mOpaqueForAnimatedGeometryRootParent =
>+            item->IsDisplayPortOpaque();
>+        scrollInfoLayerEntry.mBaseFrameMetrics =
>+            item->ComputeFrameMetrics(scrollInfoLayer, mParameters);
>+        SetupScrollingMetadata(&scrollInfoLayerEntry);

Isn't the animated geometry root for the scroll info layer going to be different in general from the current layer? Does that cause any problems? Same for the fixed pos data.

Comment 10

[Markus Stange [:mstange]]

Hmm, you're right. I didn't see any problems during testing, but there might be.

Comment 11

[Markus Stange [:mstange]]

Attachment: patch

Comment 12

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9d08f61b03f9

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9d08f61b03f9

Comment 14

[KTucker [:KTucker][Inactive 3/4/2016]]

Josh, can you verify this please?

Comment 15

[Joshua Mitchell (Inactive)]

This issue is verified fixed on today's 3.0 

Actual Results: Notification list on lockscreen scrolls with no issues

Environmental Variables:
Device: Flame Master
Build ID: 20150320010204
Gaia: 8837f94418d69a0b06c1f4843b0779e2bb72165a
Gecko: 4d2d97b3ba34
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0