966447 - [B2G][Marketplace][Sand Trap] Sand fill meter, pail, and puzzle will sometimes appear above the position on screen where they should be after force close

Status: RESOLVED DUPLICATE of bug 957276

(Core :: Graphics: Layers, defect)

Description

[Rachel Pribble [:rpribble]]

Attachment: Screenshot

Description:
When app is force closed and reopened, the sand fill meter, pail, and main puzzle will sometimes float higher than they are meant too. This makes the pail and puzzle appear floating, and the sand bar fill meter float above the designated, bordered area.

Repro Steps:
1) Updated buri to BuildID: 20140127004002
2) Launch Marketplace
3) Install Sand Trap
4) Launch Sand Trap and begin a new game
5) Complete first level and continue to second level
6) Once the second level has loaded, tap the home button
7) Long press the home button to pull up force close screen
8) Force close Sand Trap
9) Reopen Sand Trap
10) Tap the "Let's Play' button to resume game
11) Observe sand fill meter, pail, and puzzle floating above designated positions


Actual:
Force closing sometimes causes elements to float above designated areas.

Expected:
All elements of the game remain in the designated areas.

Environmental Variables: (keywords: pail, bucket, task manager, card viewer, bar)
Device: buri 1.3 moz ril
BuildID: 20140127004002
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Gecko: c40099a42c1f
Version: 28.0a2
Firmware Version: V1.2-device.cfg

Notes:

Repro frequency: 4/5, 80%
See attached: screenshot

Comment 1

[Jason Smith [:jsmith]]

I can reproduce. This is a partner app for a target market, so this pretty much has to work to be able to ship in that market for 1.3.

Comment 2

[Peter Bylenga [:PBylenga]]

This regression happened between 9-10-2013 and 9-12-2013 for buri v1.2 nightly.

Before and On 9-10-2013: the Sand Trap game runs slow, about 1-3 fps and eventually causes an OS crash.
On 9-11-2013: The download never completes for Sand Trap, eventually timing out again and again.
On and after 9-12-2013: I see the issue as described in Comment 0.

Last build issue did not reproduce on:
v1.2 Environmental Variables:
Device: Buri v1.2 MOZ
BuildID: 20130910040201
Gaia: 6deda9d7c51f278443f704217eaed722044a03e7
Gecko: be1053dc223b
Version: 26.0a1
Firmware Version: v1.2-device.cfg

Build with a separate issue that blocks reproduction:
v1.2 Environmental Variables:
Device: Buri v1.2 MOZ
BuildID: 20130911040201
Gaia: ebbb325958c66c3e68e1f190472d5f6e9076d83a
Gecko: f9e8e8ce552c
Version: 26.0a1
Firmware Version: v1.2-device.cfg

First build that the issue reproduces on:
v1.2 Environmental Variables:
Device: Buri v1.2 MOZ
BuildID: 20130912040201
Gaia: 9ffd2899eb91388f7fc1ce6f7a895a6f5f922c05
Gecko: a98569f21abe
Version: 26.0a1
Firmware Version: v1.2-device.cfg

Comment 3

[Preeti Raghunath(:Preeti)]

Jet

Please help review from Layout

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

There's a canvas and a background image.  In the provided screenshot, the canvas and background image are apparently ending up offset somehow.  The canvas is position: absolute, but the image is inline; maybe something weird with whitespace.

I'll reproduce and investigate.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

I was able to reproduce on my Buri on master.  The problem goes away when expanding the #play-area via remote developer tools.  Unfortunately it's not immediately clear if this is due to the developer tools triggering a reflow that should have happened in platform or if the developer tool is incidentally triggering either of the "resize" or "orientationchange" events that it listens for and uses to trigger its resize logic.

More investigation is required, but the likeliest explanation at this point is that the app's sampling of window.innerWidth and window.innerHeight in its resize logic triggered by the "onload" handler is happening too early and seeing slightly wrong values.  (From investigating the minified source.)

I'll pick this up again tomorrow.

Comment 6

[Kai-Chih Hu [:khu]]

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

Comment 7

[Jean Gong :jgong]

PM triaging this bug.  Andrew can you provide an update and what other impact that this bug will cause such as core app or other issue.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Instrumenting the code and further testing reveals that this is indeed likely a layout issue.  Specifically:

- the resize() logic is unrelated to the problem.  Adding dump()s reveal that (on a Buri) device, the initial resize and any subsequent resizes are always seeing a width of 320 and height of 460.

- removing the google analytics document.write to help ensure that nothing weird vis a vis HTML parsing paths did not change things.

- When this is happening, the data animation (the two square halves) in the system status bar across the top causes the canvas (which draws the bucket and play area) to move down to its correct position when present.  When the animation goes away, the canvas jumps back up to weird-town.  An easy way to trigger the animation is to use the App Manager to connect to the device while the app is active since this apparently counts as network activity at this time.  If the icon is being highlighted by the devtools so it has that red dashed line, however, no jumping occurs.
-- The icon has the following in its CSS:
  /* HACK: This enforces allocation of a dedicated layer just for this animated
   * icon, remove after bug 717872 gets fixed. */
  display: block;
  transform: perspective(0.1rem);
-- All statusbar icons have:
  float: right;
  margin: 0 0.2rem;
-- The devtools highlighter class is:
  :-moz-devtools-highlighted { outline: 2px dashed #F06!important; outline-offset: -2px!important }

- It is definitely the canvas jumping around, not the (inline) background image.

- enabling/disabling APZ has no effect

Notable layout-impacting things:
* div #play-area:
** explicit style="width: 320px; height: 373.333px; margin-top: -186px; margin-left: -160px;"
** css position: absolute; top: 50%; left: 50%;

* canvas #cvs, a child of #play-area
** has height="373" width="320"
** css position: absolute; top: 0px; left: 0px; width: 100%; height: 100%;


A separate thought is that this app's zip file is bloated by weird/insufficient optimization.  Each locale has its own entire copy of the game's 164K source code with the extremely limited set of strings at the top of the file being the only thing that varies.  Also it includes a 1.1M ogg and a 1.6M mp3 when probably only one is really needed.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

This no longer reproduces on current trunk on buri/hamachi, but does reproduce on current v1.3 on buri/hamachi.  Going to check for uplift candidates in layout and compositing.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Andrew Sutherland (:asuth) from comment #9)
> This no longer reproduces on current trunk on buri/hamachi, but does
> reproduce on current v1.3 on buri/hamachi.  Going to check for uplift
> candidates in layout and compositing.

Can someone do a reverse regression window here to find out when this last failed on 1.4, first passed on 1.4?

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

Last bad:  20140211040200 d812f80a0f1d
Firs good: 20140211160209 802d87c77e76

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d812f80a0f1d&tochange=802d87c77e76

Full non-bogus build log:
affected: 20140202040201
affected: 20140208040204
affected: 20140211040200
fixed:    20140211160209
fixed:    20140212040203

Comment 12

[Jason Smith [:jsmith]]

(In reply to Andrew Sutherland (:asuth) from comment #11)
> Last bad:  20140211040200 d812f80a0f1d
> Firs good: 20140211160209 802d87c77e76
> 
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=d812f80a0f1d&tochange=802d87c77e76
> 
> Full non-bogus build log:
> affected: 20140202040201
> affected: 20140208040204
> affected: 20140211040200
> fixed:    20140211160209
> fixed:    20140212040203

We should be able to bisect this a bit deeper, as we have tinderbox builds in that range. So let's bisect this as deep as possible using tinderbox builds.

https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

fixed in 20140211114607 e93b626422f6
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-hamachi-eng/20140211114607/

verified not fixed in the preceding build edd724161ab4 although I manually built that one.

I'll do a few more quick builds to bisect us further, especially since none of the bugs in that push really seem like they should have actually fixed the problem and make me worry I screwed up somehow.

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

So, further bisection on my part is not working out.  My locally-made hamachi gecko build of e93b626422f6 (installed via "./flash.sh gecko" after "./build gecko" after explicitly checking out the matching git revision determined via http://moztree.gregoryszorc.com/api/changeset/e93b626422f6) still had the problem (even after blowing away the objdir), whereas the "shallow_flash.sh" installed tinderbox build corresponding to the same revision did not have the problem.  I did confirm the installed version via "check_versions.sh" and everything seemed to match up correctly.

I built the following revisions locally, in the following order; incremental builds, although I also did a clean build of e93b626422f6 (though that did appear to be deriving some ccache benefit.)
affected: b7f763880106
affected: 4a99ebc2f515
affected: e93b626422f6


I'm going to crash for the night, so if someone else wants/is able to sanity check my results where it seemed like a change happened, that could be handy.  Specifically last nightly bad, first nightly good, and first nightly good.  For the nightlies I used auto_flash_from_pvt.sh, for the tinderbox I manually downloaded the tarball and used "shallow_flash.sh" (since I figured the gaia changes would likely not matter.)

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

Good news everyone!  I screwed up my gecko build checkout; my local build of the nightly confirms the fix.  The truth is:

affected: b7f763880106
affected: 4a99ebc2f515
fixed:    e93b626422f6

I'll bisect further and try and generate and test an uplift to v1.3 gecko, etc. etc.

Comment 16

[Jason Smith [:jsmith]]

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4a99ebc2f515&tochange=e93b626422f6

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

good news, bad news.

good news: I found the commit that fixed the problem. http://hg.mozilla.org/mozilla-central/rev/058f4ed4d33b
bad news: It fixed the problem by entirely breaking HWComposer on b2g.  The evil bug that broke hwcomposer was bug 963821, the good bug that turned it back on was bug 971875
good news: We know it's the HWComposer's fault!
bad news: The bug is present again on trunk (again).  The bug once again reproduce on https://hg.mozilla.org/mozilla-central/rev/339f0d450d46 using hamachi master build 20140217160203

I'm de-assigning myself because while I have experience with some layout engine internals, I have no experience with the hwcomposer.

Comment 18

[Timothy Nikkel (:tnikkel)]

The game is made up of a canvas with transparent parts and a background image. When the problem appears the canvas part is shifted up by the height of the status bar. Which is exactly the problem in bug 957276. The regression _and_ progression ranges for these two bugs match up. If they aren't dupes then they almost certainly have the same root cause.

Additionally based on comment 17 I tried enabling/disabled hardware composer in settings. When HWC is enabled I can reproduce both this bug and bug 957276 easily. When HWC is disabled this bug and bug 957276 do not happen.

So it seems like HWC has a bug about where it composites canvas layers or something?

Milan, can you find an assignee who knows more about this?

Comment 19

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

Michael, can you help us connect Sotaro with somebody on this?

Comment 20

[Diego Wilson [:diego]]

Can someone please share a logcat log?

Comment 21

[Sotaro Ikeda [:sotaro]]

I confirmed the bug on my v1.3 hamachi and master hamachi. Bug 957276 seems to be caused by same case. At first I am going to debug about Bug 957276. It seems easier to debug. I do not think it is caused by hw composer. It seems to be more like a conversion problem between Layer and HwcList(hwc_display_contents_1_t). And it seems to be triggered by Layer side.

Comment 22

[Sotaro Ikeda [:sotaro]]

From Bug 957276 Comment 96, it seems like Layer's problem. I also added logcat of "Distant Orbit" in Bug 957276.

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

I'm going to clear my logcat needinfo since it seems like Sotaro is able to repro and provide better logs and https://bugzilla.mozilla.org/show_bug.cgi?id=957276#c95 and https://bugzilla.mozilla.org/show_bug.cgi?id=957276#c99 may sufficiently cover the bug already if it's a common bug.

Comment 24

[Sotaro Ikeda [:sotaro]]

attachment 8378603 [details] [diff] [review] in Bug 957276 is a temporary fix for the bug. But the patch does not fix this bug's problem...

Comment 25

[Sotaro Ikeda [:sotaro]]

In Bug 957276, I got a log by uisng master hamachi. But I can not reproduce this bug's problem on master hamachi. I am going to get a log on v1.3 hamachi.

Comment 26

[Sotaro Ikeda [:sotaro]]

Attachment: logcat with manually added log and enable "layers.dump"

Comment 27

[Sotaro Ikeda [:sotaro]]

On "Sand Trap", main game's canvas size is (320*373). But by HwcUtils::PrepareLayerRects(), canvas size is shrunk to (320*349). And the canvas was rendered as slide up to adjust to the shrunk size. So, attachment 8378603 [details] [diff] [review] in Bug 957276 did not fix the problem. But the cause of the problem is as to Bug 957276.

Comment 28

[Sotaro Ikeda [:sotaro]]

In HwcUtils::PrepareLayerRects(), aClip is (0, 64, 320, 373) and aBufferRect is (0, 0, 320 , 373) for the canvas. PrepareLayerRects() seems to expect aBufferRect is in display coordinate. So, aBufferRect need to be (0, 64, 320 , 373) from PrepareLayerRects() point of view.

Comment 29

[Sotaro Ikeda [:sotaro]]

Attachment: logcat with manually added log and enable "layers.dump"

Update log out.

Comment 30

[Sotaro Ikeda [:sotaro]]

By the local fix, it becomes clear that this bug is dup of Bug 957276.

Comment 31

[Sotaro Ikeda [:sotaro]]

Comment was my misunderstanding, it just fallbacked to OpenGL.

Comment 32

[Sotaro Ikeda [:sotaro]]

Confirmation code was wrong. I confirmed the fix locally. This bug is dup of bug 957276.