911673 - [system] use 'scroll from device side to screen'(scroll up) gesture to back to homescreen

Status: RESOLVED FIXED

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

Description

[[e-mail]]

instead of physical button, use 'scroll from device side to screen'(scroll up) gesture to go back to homescreen

Comment 1

[[e-mail]]

carrie, please attach your spec here once its available

Comment 2

[Steven Yang [:styang]]

Carrie, could you also link the user story?

Comment 3

[Carrie Wang [New account: [e-mail]]]

Hi Neo,

Please help to clarify the issue. Thanks!

(In reply to styang from comment #2)
> Carrie, could you also link the user story?

Comment 4

[Carrie Wang [New account: [e-mail]]]

Attachment: spec-Lock screen-130909 .pdf

Attached is the spec for lockscreen.

Comment 5

[Carrie Wang [New account: [e-mail]]]

Attachment: spec-Home Screen-130909.pdf

Attached is the spec for homescreen.

Comment 6

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

I wonder the 'swipe to up' would break some other transition else.

For example, currently when we go back to homescreen, we
1) Close inline activities
2) Close app
At the same time.
Unfortunately, the transition of 'closing inline activity' is 'from top to bottom'.

This is very strange.

Could we be consistent with all window transition?
How about window.open (popup)'s transition?

Also the implementation shall be blocked by https://bugzilla.mozilla.org/show_bug.cgi?id=907013 but I don't know if I could complete it this week.

Comment 7

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

Implementation detail FYI: bug 907013 is implementing safe customizable window transition by embedding the transition type in the app window instance and process it instance by instance. I do not suggest to hack window manager to have custom transition right now. But if schedule talks.....

Comment 8

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

I saw the implementation from George's phone, there are some information for your reference:
1. transition for opening app is scale up from center of screen
2. transition for app to home is swipe from bottom to top without any scaling

looks we have two different transition between [homescreen -> app] and [app -> homescreen].

Comment 9

[Carrie Wang [New account: [e-mail]]]

(In reply to Yuren Ju [:yurenju] from comment #8)
> I saw the implementation from George's phone, there are some information for
> your reference:
> 1. transition for opening app is scale up from center of screen
> 2. transition for app to home is swipe from bottom to top without any scaling
> 
> looks we have two different transition between [homescreen -> app] and [app
> -> homescreen].

Hi Yuren,

Has it already been implemented? Can we have a look? (maybe record a video?)
just want to make sure that having two different transition is acceptable.
Thanks! :)

Comment 10

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

In reply to comment 9,
Carrie, I didn't implement the gesture animation in this patch. Obviously, we need more time for discussion and tuning, and it won't not meet the deadline.

This patch only finish the actions to home/cardview.

Comment 11

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

(In reply to cawang from comment #9)
> (In reply to Yuren Ju [:yurenju] from comment #8)
> > I saw the implementation from George's phone, there are some information for
> > your reference:
> > 1. transition for opening app is scale up from center of screen
> > 2. transition for app to home is swipe from bottom to top without any scaling
> > 
> > looks we have two different transition between [homescreen -> app] and [app
> > -> homescreen].
> 
> Hi Yuren,
> 
> Has it already been implemented? Can we have a look? (maybe record a video?)
> just want to make sure that having two different transition is acceptable.
> Thanks! :)

Let's hold a small intro + discussion for all app/activity transitions in gaia now when we back to Taipei.

Comment 12

[(Inactive after June) George Duan [:gduan] [:喬智]]

This bug will only not include animation since we need time to tune for all types of cases, like prompt, alert, windows.open, attention screen, and normal opening/closing.

However, for my current action-only patch, I'm still investigating how to solve below bugs.
1. when some button is on the background of the transparent bar 
2. how to close utility tray 
3. how to open e.me's wrapper bar .

Comment 13

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 803599 [details]
PR to master

Hi Alive,

Could you help me to take a look of this patch?

I only implement the action part here, since the animation part may takes time to implement and discussion.

I will open below bugs for follow-up.
1. closing/opening/cardview animation for all types of screen
2. wrapper navigation bar for e.me
3. inari doesn't support multi horizontal touches

Comment 14

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

Comment on attachment 803599 [details]
PR to master

Where's the window manager transition change?
And use feedback next time for WIP.

Comment 15

[(Inactive after June) George Duan [:gduan] [:喬智]]

Hi Alive,

For transition change, I will open a followup bug for it.

This patch should meet the action part. However, keyboard/alert/prompt will block my gesture bar and I'm not sure how to fix that. Could you advise how to fix that?

(In reply to Alive Kuo [:alive] from comment #14)
> Comment on attachment 803599 [details]
> PR to master
> 
> Where's the window manager transition change?
> And use feedback next time for WIP.

Comment 16

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

offline discussion.

Comment 17

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 803599 [details]
PR to master

Hi Alive,

I update my solution as below.
|this.homeBar.addEventListener('click', this, true);|
I found if I also listen click event here, then keyboard/alert/prompt would not steal my touchstart/end event. Please kindly review it again. 
Thanks.

Comment 18

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

Comment on attachment 803599 [details]
PR to master

See comments. and Please try to have unit tests.

Comment 19

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 803599 [details]
PR to master

Hi Alive,

Patch is updated and also added some test cases. Please kindly review again. 
Thanks for your patience!

Comment 20

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

Comment on attachment 803599 [details]
PR to master

Great work, r=me, thanks for the patience.

Comment 21

[(Inactive after June) George Duan [:gduan] [:喬智]]

Thanks Alive, I updated as your comment again.

Merge into master.
https://github.com/mozilla-b2g/gaia/commit/0dedb5b3789afc638a0c7c67652937fcb30e77d2

Comment 22

[(Inactive after June) George Duan [:gduan] [:喬智]]

Open bug 918272 for animation.

Comment 23

[Juwei Huang[:juwei]]

Attachment: LockScreen_20130923.zip

Hi all,
Lock screen layout spec (landscape only) updated.

Comment 24

[Juwei Huang[:juwei]]

Hi all,
Home screen & Card view layout specs uploaded.
Please check the server: 
//fileserver1/Public/UX/[Firefox OS] Tablet/Lockscreen

Thanks,
Juwei

Comment 25

[James Lal [:lightsofapollo]]

Uplifted 0dedb5b3789afc638a0c7c67652937fcb30e77d2 to:
v1.2: 812700755f4556fb44325693fa35cb29a8fa9f11

Comment 26

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Whoa.  How does this not break any app that needs to use a gesture that looks a lot like a "swipe upwards"?  Or not even a gesture, where the user might make such a gesture while interacting with the app?