Closed Bug 957391 Opened 6 years ago Closed 6 years ago

[B2G][Game Pack] Backing out of a game will lead to a blank page in the Game Pack app

Categories

(Core :: Layout, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30
blocking-b2g 1.3+
Tracking Status
firefox28 --- wontfix
firefox29 --- fixed
firefox30 --- fixed
b2g18 --- unaffected
b2g-v1.2 --- wontfix
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: jschmitt, Assigned: sotaro)

References

Details

(Keywords: regression, Whiteboard: dogfood1.3)

Attachments

(3 files, 5 obsolete files)

Attached image Blank_Page
Description:
Sometimes when pressing the 'back' button, the app will show a blank yellow page

Repro Steps:
1) Updated Buri to BuildID: 20140106004001
2) Proceed to the Marketplace
3) Download the 'Game Pack' app
4) Load the 'Game Pack' app
5) Select 'Tower Jelly'
6) Start the game
7) Select the 'back' button

Actual:
The app goes to a blank yellow screen

Expected:
The app to go to the apps homepage

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140106004001
Gaia: 35a60b82f8cf2d759939a350e2dadbb9d8b2f5dc
Gecko: a43cb4b322d3
Version: 28.0a2
Firmware Version: V1.2_20131115
Issue occurs on 1.2 buri build, but does NOT occur in 1.1

Environmental Variables:
Device: Buri 1.2 COM
BuildID: 20140106004001
Gaia: 8441587c3b352e052fee07665c21fd192540f19f
Gecko: d552c08a72d0
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version: V1.2_20131115

Environmental Variables:
Device: Buri 1.1 COM
BuildID: 20140107041207
Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f
Gecko: 66c4a3131c39
Version: 18.0
RIL Version: 01.01.00.019.281
Firmware Version: V1.2_20131115
We need a logcat for this bug. I'm unsure what would cause this.
blocking-b2g: --- → 1.3?
Keywords: qawanted, regression
Attached file Logcat.txt (obsolete) —
I have attached a logcat of the bug.
Keywords: qawanted
Attached file Logcat.txt (obsolete) —
Update the Logcat with console enabled.
Attachment #8356872 - Attachment is obsolete: true
QA Contact: sparsons
This issue occurs on every build all the way back to the first Buri 1.2 Build ID: 20130621031231

Gaia   e2f19420fa6a26c4287588701efaec09a750dba1
SourceStamp 7ba8c86f1a56
BuildID 20130621031231
Version 24.0a1
QA,

What is the path to recovery from the yellow blank screen?

Also, why is it a regression since it was seen in 1.2?

UX,

Do you believe the back button needs to take us to homscreen? or somewhere else.
Flags: needinfo?(firefoxos-ux-bugzilla)
Keywords: qawanted
Checked on peak and the issue is not seen.
What is the path to recovery from the yellow blank screen?

Tapping on the yellow screen will resolve the issue. 

Also, why is it a regression since it was seen in 1.2?

This was marked as a regression because it doesn't occur on 1.1


(In reply to Preeti Raghunath(:Preeti) from comment #6)
> QA,
> 
> What is the path to recovery from the yellow blank screen?
> 
> Also, why is it a regression since it was seen in 1.2?
> 
> UX,
> 
> Do you believe the back button needs to take us to homscreen? or somewhere
> else.
Keywords: qawanted
(In reply to Preeti Raghunath(:Preeti) from comment #6)
> QA,
> 
> What is the path to recovery from the yellow blank screen?

Recovery doesn't matter here. We have a firm requirement that preinstalled partner apps have to work consistently across releases in the same manner for our target markets. If there are regressions found & it's our fault, then we have to fix it. Otherwise, we won't be able to sign off during IOT cycles that the preinstalled apps work for a particular target market.

This is a partner content blocker.

> 
> Also, why is it a regression since it was seen in 1.2?

Because no one caught this in 1.2. It doesn't happen on 1.1, which makes this is a regression from 1.1.

> 
> UX,
> 
> Do you believe the back button needs to take us to homscreen? or somewhere
> else.

This isn't a UX decision - this is a content decision on the workflow by the partner & the relevant partner engineer.
Flags: needinfo?(firefoxos-ux-bugzilla)
Thank you, Jason. Yes to all of the above.
1.3+ as it blocks a partner

Fabrice,

please help reassign
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(fabrice)
I just tried reproducing using latest v1.3 branch, and it works for me.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(fabrice)
Resolution: --- → WORKSFORME
(In reply to James Burke [:jrburke] from comment #12)
> I just tried reproducing using latest v1.3 branch, and it works for me.

Note - if this no longer reproduces, we need to have someone try to retest this who could originally reproduce it to confirm it. It could be misleading STR that could be the reason why the bug can't be reproduced, so let's make sure someone verifies this.

Reopening & adding qawanted to confirm that this no longer reproduces on 1.3.
Status: RESOLVED → REOPENED
Keywords: qawanted
Resolution: WORKSFORME → ---
I can still reproduce this issue on the Buri 1.3 Build ID: 20140130004001

Gaia   8defa5bf0cbce290c649e564b7f3ebe708e19b23
SourceStamp 6b12800e0e46
BuildID 20140130004001
Version 28.0a2
Keywords: qawanted
OK, so there is a missing step after step 7:

8) Press Home icon in lower right corner to go back to the apps. 

I was able to save a tap by using these steps:

1) Updated Buri to BuildID: 20140106004001
2) Proceed to the Marketplace
3) Download the 'Game Pack' app
4) Load the 'Game Pack' app
5) Select 'Tower Jelly'
6) Wait for 'Tower Jelly' to load.
7) When it says 'Tap to continue', instead of tapping that, tap the Home button in the lower right corner.

This results in the yellow screen.

It only seems to happen on first launch. After getting the yellow screen, if I turn off the screen then back on and unlock, the expected game list is showing. If I then tap 'Tower Jelly' and tap the home button it works fine.

Similarly, if I just long-press the home button then select the app again, it draws fine. So seems to be some sort of paint issue.

Disabling APZ for Apps does not fix it, and there is no error in the logcat. Unfortunately, I am out of my depth now on this bug and will not be able to track down a fix, so restoring the needsinfo for fabrice on the bug.
Flags: needinfo?(fabrice)
I don't know what could prevent painting... moving the needinfo to Milan and his team.
Flags: needinfo?(fabrice) → needinfo?(milan)
Sotaro, can you reproduce this on 1.3 Buri?  See comment 15 for the STR.
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(milan) → needinfo?(sotaro.ikeda.g)
I confirmed the problem happens on latest v1.3 hamachi.
Flags: needinfo?(sotaro.ikeda.g)
Attached image game's menu resource
I locally downloaded the "Game Pack". The Game menu is consisted as one jpg image "menu.jpg". It is set as background-image like the following. When the problem happens the background-image seems not drawn at all.

> body {
>	background-image: url("./menu.jpg");
>	background-repeat: no-repeat;
>	background-position: center;
>	background-size: contain;
>	background-color: #fedf32;
> }
I did not attached the game zip file. The size is about 5MB. I am not sure that it is OK to attach such size to bugzilla.
Can we get ETA to fix this bug? Thank you.
I locally changed the image loading to sync by modifying nsCSSRendering::PrepareBackgroundLayer(). The problem did not happen.
 http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSRendering.cpp#2916
From comment 22, the problem seems around layout or ImageLib. It it is related to ImageLib, Bug 716140 might be related.
Component: General → Layout: Images
Product: Firefox OS → Core
Component: Layout: Images → Layout
Attached file logout (obsolete) —
From logout, "menu.jpg" is loaded asynchronously. And since the image load complete, there seems no rendering update.
Whiteboard: dogfood1.3 → dogfood1.3, [ETA: 2/14]
Just adding Seth as he's been covering async decoding for any ideas.
Flags: needinfo?(seth)
In attachment 8370570 [details], the game app body's background-image was rendered like the following. The "menu.jpg" was not decoded yet. Therefore it is not rendered on the screen. Just background color is rendered as yellow.

>   706   706 I Gecko   : CanvasBackgroundImage 0x43823978() bounds(0,0,0,0) visible(0,0,0,0) componentAlpha(0,0,0,0) clip() 
>   706   706 I Gecko   :  layer=0x435a38c0
When "menu.jpg" is decoded. ImageLoader::DoRedraw() is called. But it does not call actual redraw function.

ImageLoader::Notify()
 ->ImageLoader::FrameChanged()
   ->ImageLoader::DoRedraw()
     ->FrameLayerBuilder::IterateRetainedDataFor()
      // nsIFrame does not have "nsTArray<DisplayItemData*>" as a property.
      // redraw does not handled correctly.
This is just a temporary patch to confirm the cause of the problem. By the patch, the problem is fixed. But it can not be used for check-in.
This bug seems very similar to Bug 844750.
:mattwoodrow, can you take this bug? You know very well around these source code.
Flags: needinfo?(matt.woodrow)
I think we just need to move the aFrame->SchedulePaint(); out of the callback, and put it after the IterateRetainedDataFor() call.
Thanks for the advice. I am going to try it.
Flags: needinfo?(matt.woodrow)
Confirmed the patch fixes the problem.
Attachment #8371839 - Attachment is obsolete: true
Attachment #8372294 - Flags: review?(matt.woodrow)
Flags: needinfo?(seth)
Attachment #8372294 - Flags: review?(matt.woodrow) → review+
Committable patch. Carry "r=mattwoodrow".
Attachment #8356897 - Attachment is obsolete: true
Attachment #8370570 - Attachment is obsolete: true
Attachment #8372294 - Attachment is obsolete: true
Attachment #8373339 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/64b3f71d79a8
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.