bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

VERIFIED FIXED in Firefox 39, Firefox OS v2.2

Status

()

Core
Layout
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Joshua Mitchell (Inactive), Assigned: mstange)

Tracking

({regression})

unspecified
mozilla39
ARM
Gonk (Firefox OS)
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.5?, firefox37 wontfix, firefox38 wontfix, firefox39 fixed, b2g-v2.2 fixed, b2g-master verified)

Details

(Whiteboard: [3.0-Daily-Testing], URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8575346 [details]
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
(Reporter)

Comment 1

3 years ago
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Functional regression of a core feature.

Requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
QA Contact: pcheng
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Markus, can you take a look at this please? Looks like the landings for bug 913443 might have caused this to occur.
Flags: needinfo?(ktucker) → needinfo?(mstange)
(Assignee)

Comment 5

3 years ago
I'll look at it.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Flags: needinfo?(mstange)
(Assignee)

Comment 6

3 years ago
Created attachment 8576912 [details] [diff] [review]
patch

This might work. I haven't tested it yet.
Attachment #8576912 - Flags: review?(tnikkel)

Updated

3 years ago
Component: Gaia::System::Lockscreen → Layout
Product: Firefox OS → Core
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.
Attachment #8576912 - Flags: review?(tnikkel) → review+
(Assignee)

Updated

3 years ago
Blocks: 913443
(Assignee)

Comment 8

3 years ago
Created attachment 8577548 [details] [diff] [review]
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.
Attachment #8576912 - Attachment is obsolete: true
Attachment #8577548 - Flags: review?(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.
(Assignee)

Comment 10

3 years ago
Hmm, you're right. I didn't see any problems during testing, but there might be.
(Assignee)

Comment 11

3 years ago
Created attachment 8578307 [details] [diff] [review]
patch
Attachment #8577548 - Attachment is obsolete: true
Attachment #8577548 - Flags: review?(tnikkel)
Attachment #8578307 - Flags: review?(tnikkel)
Attachment #8578307 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/mozilla-central/rev/9d08f61b03f9
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Josh, can you verify this please?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(jmitchell)
Keywords: verifyme
(Reporter)

Comment 15

3 years ago
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
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
status-b2g-master: affected → verified
Flags: needinfo?(jmitchell)
(Reporter)

Updated

3 years ago
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: verifyme
(Assignee)

Updated

3 years ago
Depends on: 1144307
status-b2g-v2.2: unaffected → fixed
status-firefox37: --- → wontfix
status-firefox38: --- → wontfix
You need to log in before you can comment on or make changes to this bug.