Closed Bug 1018487 Opened 8 years ago Closed 8 years ago
[B2G][Gaia]Cut the Rope is not correctly displayed when launched
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
QA Wanted to check 1.4.
Component: Gaia → Gaia::System::Window Mgmt
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
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?
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.
Alive, please recommend the next step of this bug?
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.
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: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1018836
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.