Closed Bug 1018487 Opened 10 years ago Closed 10 years ago

[B2G][Gaia]Cut the Rope is not correctly displayed when launched

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 affected)

RESOLVED DUPLICATE of bug 1018836
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- affected

People

(Reporter: astole, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached file logcat
The Cut the Rope game is partially off the screen so it cannot be played.

Repro Steps:
1) Update a Flame to BuildID: 20140530040207
2) Open the marketplace
3) Search for and download the Cut the Rope game
4) Launch Cut the Rope

Actual:
Cut the Rope is not properly displayed

Expected:
Cut the Rope is in the center of the screen and playable

2.0 Environmental Variables:
Device: Flame 2.0 MOZ
BuildID: 20140530040207
Gaia: 26d8fcab9b61f46451600f39c51e0387ef3c4f88
Gecko: e6f113c83095
Version: 32.0a1
Firmware Version: v10G-2

Repro frequency: 100%, 2/2
See attached: Screenshot, logcat
Attached image Screenshot
QA Wanted to check 1.4.
Component: Gaia → Gaia::System::Window Mgmt
Keywords: qawanted
User agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

This issue does not occur on the latest 1.4. Cut the Rope launches and is correctly displayed.

1.4 Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140530000202
Gaia: fe612fd21389193a8e593aa718831602e5086a62
Gecko: 25011f9a8f26
Version: 30.0
Firmware Version: v10G-2
blocking-b2g: --- → 2.0?
B2G Inbound Regression Window

Last Working
Environmental Variables:
Device: Flame
BuildID: 20140528233003
Gaia: eced604040a970e65dfb51fa83e1a18a9d00b7db
Gecko: fe9a8825a3ae
Version: 32.0a1
Firmware Version: v30G-2

First Broken
Environmental Variables:
Device: Flame
BuildID: 20140529075121
Gaia: d5dcbabd1ad07d5fd30a7875a9a80817bc93619c
Gecko: f72106cb1769
Version: 32.0a1
Firmware Version: v10G-2

Last Working Gaia First Broken Gecko:  Issue does NOT reproduce
Gaia: eced604040a970e65dfb51fa83e1a18a9d00b7db
Gecko: f72106cb1769

First Broken Gaia Last Working Gecko: Issue DOES reproduce
Gaia: d5dcbabd1ad07d5fd30a7875a9a80817bc93619c
Gecko: fe9a8825a3ae

Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/eced604040a970e65dfb51fa83e1a18a9d00b7db...d5dcbabd1ad07d5fd30a7875a9a80817bc93619c
QA Contact: jharvey
Another fallout from bug 950673.

Tim - Can you find someone to look into this issue?
Blocks: 950673
Flags: needinfo?(timdream)
Second question we'll want to answer - if bug 950673 gets uplifted, then will this problem reproduce on 1.4? If so, we'll probably want to block this for 1.4.
Flags: needinfo?(timdream) → needinfo?(gasolin)
Remove bug 950673 patch from master fixed this issue. I think it will happen in 1.4 if we uplift bug 950673.

We need find out the root cause before uplift bug 950673 to 1.4.
Flags: needinfo?(gasolin)
Depends on: popup-window
No longer depends on: popup-window
blocking-b2g: 2.0? → 2.0+
Alive, please recommend the next step of this bug?
Flags: needinfo?(alive)
I'd rather to think this IS a cut-the-rope bug or gecko bug, but I don't have some time to read its code...
The reason is for other landscape app it's really not broken with bug 950673.
Flags: needinfo?(alive)
Here is my finding with App Manager on Flame:

1. I can verify the app frame is correctly sized in System app (569x320).
2. However, the app <html> within is INCORRECTLY sized. (569x445)
3. The body is correctly sized (569x320) but in correctly positioned (being pushed downward ~3/5 of the screen width)
4. Issuing |location.reload()| in the App Manager to reload the app frame fix the issue \o/

Given the finding and the nature of bug 950673, I agree this is a platform timing issue triggered by the new launching timing introduced by bug 950673.

Tentatively throwing this to Core::Layout, please move to FxOS::General if this is not the case.
Component: Gaia::System::Window Mgmt → Layout
Product: Firefox OS → Core
PS this does not happen on Unagi, which suggests either the timing issue doesn't happen on slower phone or this bug simply does not happen on 1dppx phones.
Well.. sorry, I accidently found patch of bug 1018836 fixed this.
My guess: cut-the-rope is really to heavy -- this is the reason why this only happens to cut-the-rope but not other landscape games -- to load before the transition timeout.
But we are locking the device in the opened handler to prevent reflow during animation occurs.(Even the orientation is portrait the lock call will cause reflow).

Bug 1018836 fixes the immediate transition with proper state control. I think we could dupe this two bugs.
Component: Layout → Gaia::System::Window Mgmt
Product: Core → Firefox OS
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
To rephrase what Alive said offline, bug 1018836 ensures CutTheRope frames loads at the time orientation change is completed. I am still not sure of whether or not we had triggered a platform bug or CutTheRope itself simply reads the window sizes when it loads without response to resizing later. Let investigate if we run into the same issue afterward.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: