Closed Bug 1057300 Opened 10 years ago Closed 10 years ago

[B2G2.1] For Some applications black screen appears in the card view

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.4 unaffected, b2g-v2.0 unaffected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED DUPLICATE of bug 1062136
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: srinivasvemula.mtech, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 Steps to reproduce: 1) Open Application 2) Press Home Button 3) Repeat step 1 and 2 for 9-10 application 4) Press the power button for lock the screen 5) Press the power button again for Unlock the screen 6) Press and hold the Home key for see the open apps cardviews 7) Check each card view screen Actual results: Block screen preview appears in all remaining card views after switching 4 or 5 card views. Expected results: preview should appear in card views for all opened applications
Flags: needinfo?(jsmith)
Flags: needinfo?(alive)
Flags: needinfo?(aus)
Flags: needinfo?(seth)
What version is this being tested on?
Flags: needinfo?(jsmith)
Summary: [B2G2.0] For Some applications black screen appears in the card view → [B2G2.1] For Some applications black screen appears in the card view
B2G2.1 version Device: Nexu4
Flags: needinfo?(jsmith)
So Nexus isn't a production supported device, so I don't think I can help you here.
Flags: needinfo?(jsmith)
This is definitely news to me. We do have some issues on Nexus 4 since it isn't a production supported device as Jason pointed out. We haven't seen this problem on any of our production devices. It's possible that there's a failure to cache the screenshot that's then used to create the card itself. This code lives in the system app in apps/js/task_manager.js apps/js/task_card.js and apps/js/card.js iirc. This would be the place to start to try and diagnose what's going on. Specifically the code that draws the card. It's unlikely that any of the system team folks will be able to get to this anytime soon. Our plates are all quite full, but if you submit a pull request we'd be happy to review! :)
Flags: needinfo?(aus)
I've seen this on my Flame with 2.1/trunk. When I looked in app-manager/inspector, the _screenshotBlob was missing (I'm sure), and _screenshotOverlayState was 'none' (I think). If for whatever reason we don't have a blob to show there, we should at least show the icon. No concrete STR though, I've just seen it sometimes when I reboot the phone and an app is already running and shows up in cards view (usually Phone, though that could simply be because that's what I've been testing most)
when we open 9 to 10 applications simultaneously without closing previous applications then this issue is reproducible. For 4 to 5 opened applications this issue is not reproducible. As per Comment 5 I think it is possible to reproduce this issue on production devices.
Flags: needinfo?(jsmith)
Flags: needinfo?(aus)
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Sam is looking, clear.
Flags: needinfo?(alive)
Ok - marking qawanted for branch checks.
Flags: needinfo?(jsmith)
Keywords: qawanted
I have not been able to Repro this in Flame 2.1 - After opening 10 aps and entering card view, all aps look normal. Locking and Unlocking the phone does not produce any blank card views. Device: Flame Master Build ID: 20140825085054 Gaia: a25ae14dbd2fe3e25144a7064efc0cc4e31042b8 Gecko: 4ca2bd0722d9 Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Will leave QA-Wanted tag on for now to see if anyone can verify a solid repro (on Flame) *Please note - there is a current bug where browser is shown as a blank card-view after pushing a new build (you don't even launch browser, it just starts running in the background after flashing). I can't find the bug # but please make sure you do not confuse that issue with this issue.
Flags: needinfo?(jsmith)
Flags: needinfo?(jsmith)
(In reply to Sam Foster [:sfoster] from comment #5) > I've seen this on my Flame with 2.1/trunk. When I looked in > app-manager/inspector, the _screenshotBlob was missing (I'm sure), and > _screenshotOverlayState was 'none' (I think). You're talking about JavaScript variables here, right? (I haven't taken a look at the code.) If so, this sounds like an issue in the code that manages these cards, not a platform-level issue. If I'm wrong about that, please needinfo me again.
Flags: needinfo?(seth)
These javascript properties are just confirmation of the symptoms, the cards are appearing black because there is no screenshot. Its likely there are 2 bugs here - in the event that for whatever reason the AppWindow and/or CardsView doesn't have a screenshot for a given window, it should be falling back to hiding the screenshot container in the DOM and showing the icon instead - as I understand it. Then, the other issue is why is there no screenshot? That second issue might still be platform-level. The front-end piece is in/around https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/browser_mixin.js#L65 and https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_window.js#L188
Flags: needinfo?(seth)
Sorry, but I don't think I'm the best person to debug this, and I still don't think we have enough information to conclude that this is a platform-level issue. Presumably if it *is* a platform issue, you'd be able to detect the error in BrowserElementChild._takeScreenshot() in |dom/browser-element/BrowserElementChildPreload.js|. The platform stuff here essentially boils down to the drawWindow() and toBlob() calls.
Flags: needinfo?(seth)
I am only able to repro this issue with about a 1/10 frequency using the following repro steps. I'm attaching an image of the actual results. Prerequisites: 1) Have a sim pin enabled. 2) DUT is not plugged in to any other device through USB. Repro steps: 1) Restart the device 2) Slide the toggle to the right to unlock homescreen when it appears 3) Tap the home button to clear the sim pin prompt 4) Tap the messages app then, before it has finished loading, quickly tap the home button then long press the home button to bring up card viewer Actual Results: The card viewer will appear with the card and background showing black, only the 'x' in the upper left of the card is visible. Expected Results: Card content is visible in the card viewer. Device: Flame 2.1 BuildID: 20140902040205 Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c Gecko: c360f3d1c00d Version: 34.0a1 (2.1) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Contact: rpribble
Attached image Screenshot.png
I am able to repro this issue with about a 9/10 frequency using the following repro steps. I'm attaching an image of the actual results. Prerequisites: 1) Have a sim pin enabled. 2) DUT is not plugged in to any other device through USB. Repro steps: 1) Restart the device 2) Slide the toggle to the right to unlock homescreen when it appears 3) Tap the home button to clear the sim pin prompt 4) Tap the messages app then, before it has finished loading, quickly tap the home button then long press the home button to bring up card viewer Actual Results: The card viewer will appear with the card and background showing black, only the 'x' in the upper left of the card is visible. Expected Results: Card content is visible in the card viewer. Device: Flame 2.1 BuildID: 20140902040205 Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c Gecko: c360f3d1c00d Version: 34.0a1 (2.1) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
This issue DOES reproduce on the Flame v2.2. Device: Flame 2.2 Master BuildID: 20140903040203 Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f Gecko: e58842c764dd Version: 35.0a1 (2.2 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Cards display black in the card viewer. ------------------------------------------ This issue does NOT reproduce on the Flame v2.0, Flame v1.4. Device: Flame 2.0 BuildID: 20140903000206 Gaia: 449d8db9b3ea1f9262db822c37ef2143477172b7 Gecko: 13b41e22c8f6 Version: 32.0 (2.0) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Device: Flame 1.4 BuildID: 20140902000203 Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54 Gecko: 6021b50bbed0 Version: 30.0 (1.4) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 Card viewer displays as expected.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: regression
triage - not nomming, there seems to be a lot of steps involved to repro - steps the average user will not take.
Yep, I've now observed this on 2.1 and master on Flame (Full and 319) so, memory doesn't seem to have anything to do with it. We're just failing to repaint when the screenshot is available, if we were failing to get the screenshot, dragging the card would *not* fix the painting issue.
Flags: needinfo?(aus)
Issue is reroducible on 2.2 also. I think this issue is due to the limitation of max memory for decoding the images. I changed "image.mem.hard_limit_decoded_image_kb" limit 66560(65MB) to 131702(128MB) in gecko\b2g\app\b2g.js. After this change I could able to see upto 18-19 Cardviews(apps) without any blackscreen in 2.0, 2.1 and 2.2.Beyond this(18-19 cardviews) again issue is reproducing in 2.0, 2.1 and 2.2. So this could be the platform issue.
Flags: needinfo?(sfoster)
Flags: needinfo?(aus)
See my comments on bug 1064157, these all seem like different symptoms of the same problem: we are using (and possibly leaking) too much memory and the cards view is one of the aspects of the system app where it is visible. As I said on 1064157 though, even if we identify a leak we will still run into this problem eventually and need a strategy here. Copy/paste follows: AFAIK we don't currently actively manage the number of app window screenshots we keep, or the number of apps displayed in the card view (or edge swipe - which uses the same stack). It seems like at some threshold that is based on total memory of the device, we should remove the screenshot for app windows lower down the stack. We also need to add logic to consumers of the screenshots to be able to display the app icon when no screenshot is available.
Flags: needinfo?(sfoster)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(aus)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: