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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Josh Schmitt [Joshs]]

Attachment: 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

Comment 1

[Josh Schmitt [Joshs]]

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

Comment 2

[Jason Smith [:jsmith]]

We need a logcat for this bug. I'm unsure what would cause this.

Comment 3

[Josh Schmitt [Joshs]]

Attachment: Logcat.txt

I have attached a logcat of the bug.

Comment 4

[Josh Schmitt [Joshs]]

Attachment: Logcat.txt

Update the Logcat with console enabled.

Comment 5

[Sarah Parsons]

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

Comment 6

[Preeti Raghunath(:Preeti)]

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.

Comment 7

[Preeti Raghunath(:Preeti)]

Checked on peak and the issue is not seen.

Comment 8

[Sarah Parsons]

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.

Comment 9

[Jason Smith [:jsmith]]

(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.

Comment 10

[Stephany Wilkes]

Thank you, Jason. Yes to all of the above.

Comment 11

[Preeti Raghunath(:Preeti)]

1.3+ as it blocks a partner

Fabrice,

please help reassign

Comment 12

[James Burke [:jrburke]]

I just tried reproducing using latest v1.3 branch, and it works for me.

Comment 13

[Jason Smith [:jsmith]]

(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.

Comment 14

[Sarah Parsons]

I can still reproduce this issue on the Buri 1.3 Build ID: 20140130004001

Gaia   8defa5bf0cbce290c649e564b7f3ebe708e19b23
SourceStamp 6b12800e0e46
BuildID 20140130004001
Version 28.0a2

Comment 15

[James Burke [:jrburke]]

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.

Comment 16

[[:fabrice] Fabrice Desré]

I don't know what could prevent painting... moving the needinfo to Milan and his team.

Comment 17

[Milan Sreckovic [:milan] (needinfo for best results)]

Sotaro, can you reproduce this on 1.3 Buri?  See comment 15 for the STR.

Comment 18

[Sotaro Ikeda [:sotaro]]

I confirmed the problem happens on latest v1.3 hamachi.

Comment 19

[Sotaro Ikeda [:sotaro]]

Attachment: 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;
> }

Comment 20

[Sotaro Ikeda [:sotaro]]

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.

Comment 21

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 22

[Sotaro Ikeda [:sotaro]]

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

Comment 23

[Sotaro Ikeda [:sotaro]]

From comment 22, the problem seems around layout or ImageLib. It it is related to ImageLib, Bug 716140 might be related.

Comment 24

[Sotaro Ikeda [:sotaro]]

Attachment: logout

From logout, "menu.jpg" is loaded asynchronously. And since the image load complete, there seems no rendering update.

Comment 25

[Milan Sreckovic [:milan] (needinfo for best results)]

Just adding Seth as he's been covering async decoding for any ideas.

Comment 26

[Sotaro Ikeda [:sotaro]]

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

Comment 27

[Sotaro Ikeda [:sotaro]]

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.

Comment 28

[Sotaro Ikeda [:sotaro]]

Attachment: temporary patch - always call nsIFrame::InvalidateFrame()

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.

Comment 29

[Sotaro Ikeda [:sotaro]]

This bug seems very similar to Bug 844750.

Comment 30

[Sotaro Ikeda [:sotaro]]

:mattwoodrow, can you take this bug? You know very well around these source code.

Comment 31

[Matt Woodrow (:mattwoodrow)]

I think we just need to move the aFrame->SchedulePaint(); out of the callback, and put it after the IterateRetainedDataFor() call.

Comment 32

[Sotaro Ikeda [:sotaro]]

Thanks for the advice. I am going to try it.

Comment 33

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Call nsIFrame::SchedulePaint() in ImageLoader::DoRedraw()

Confirmed the patch fixes the problem.

Comment 34

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=db2bd7344b41

Comment 35

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=5ad999a220af

Comment 36

[Sotaro Ikeda [:sotaro]]

Attachment: patch v2 - Call nsIFrame::SchedulePaint() in ImageLoader::DoRedraw()

Committable patch. Carry "r=mattwoodrow".

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/64b3f71d79a8

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/64b3f71d79a8

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/99fe24b26a77