908601 - Support new |default orientation| API in system app.

Status: RESOLVED FIXED

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

Description

[(inactive after 6/18) Alive Kuo [:alive]]

Bug 908058 would introduce a new orientation string "default".
However system app is rotating the app window according to current orientation keyword(portrait or landscape). A new string in manifest would make it fail to do transition and everything after opened transition would break. We need to fix this.

Comment 1

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/12184

WIP: Support default orientation in gaia.

Comment 2

[(inactive after 6/18) Alive Kuo [:alive]]

Uh, we need to virtualize the 'landscape' and 'portrait' concept if we have 'default'.

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

On this now, WIP
https://github.com/alivedise/gaia/compare/bugzilla;908601_master_v2;default-orientation?expand=1

Note: it's still buggy!
Also see discussion in bug 925115.

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

OK, so what's blocking me now is:
If I do the following before the opening animation if the frame isn't loaded, the animation stops
 (A) Set width/height of the frame
 (B) Lock screen orientation (I think this has same effect as (A) because document's width/height is changed.)

What I observed from android:
If I opened a landscape app from homescreen, there's no enlarging transition as normal app has.
If I closed a landscape app to homescreen, there's no reducing transition as normap app has.

I was thinking changing the mechanism again to avoid all these trouble: No reflow, no stopping animation...

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Alive Kuo [:alive] from comment #4)
> OK, so what's blocking me now is:
> If I do the following before the opening animation if the frame isn't
> loaded, the animation stops
>  (A) Set width/height of the frame
>  (B) Lock screen orientation (I think this has same effect as (A) because
> document's width/height is changed.)
> 
> What I observed from android:
> If I opened a landscape app from homescreen, there's no enlarging transition
> as normal app has.
> If I closed a landscape app to homescreen, there's no reducing transition as
> normap app has.
> 
> I was thinking changing the mechanism again to avoid all these trouble: No
> reflow, no stopping animation...

I think for now it won't hurt to mimick android and one can try to implement a better animation at some point if someone can find some free time. Don't kill yourself on that.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/12785

Support default orientation
0. Add some method in ScreenLayout
1. Remove unnecessary resize from cold launch
2. Use default width/height config for different config
3. Remove all appWindow rotation
4. Use rotatingDegree instead of literal orientation string in AppWindow and Cardview
5. Try to resolve stopping-animation of landscape app opening/closing: reduce the timing of opening and fadeout the homecreen frame on opening app, fadeout the app on opening homescreen

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 815749 [details]
https://github.com/mozilla-b2g/gaia/pull/12785

Overall it looks ok, however I would worry patch this size could generate regression. We should address that in a timely matter if it happens.

Also, it look like there is one test failure here

https://travis-ci.org/mozilla-b2g/gaia/jobs/12504058#L1499

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

All mighty travis please bless me magic power.
https://travis-ci.org/mozilla-b2g/gaia/builds/12597189

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

Change a little bit in unit test
https://travis-ci.org/mozilla-b2g/gaia/builds/12671328

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Green, merging and watch for regression.
https://github.com/mozilla-b2g/gaia/commit/6238e6f95772764bebf2ecc2b18ceb804e51c1e2

Comment 11

[John Ford [:jhford] CET/CEST Berlin Time]

I was not able to uplift this bug to v1.2.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.2
  git cherry-pick -x -m1 6238e6f95772764bebf2ecc2b18ceb804e51c1e2
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

1.2
https://github.com/mozilla-b2g/gaia/commit/52703aec82e8e8a89a82a31da6ddb8a9b9680333

Comment 13

[Jason Smith [:jsmith]]

This was backed out of 1.2 for causing bug 933572:

https://github.com/mozilla-b2g/gaia/commit/3259ac8a9813740ffc43a5e4fdff8e4a024a56c8

Removing blocking-b2g flag so that this doesn't get uplifted to 1.2.