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

RESOLVED FIXED

Status

Firefox OS
Gaia::System
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: gasolin@mozilla.com, Assigned: gduan)

Tracking

(Blocks: 1 bug)

unspecified
Other
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:koi+, b2g-v1.2 fixed)

Details

Attachments

(4 attachments)

(Reporter)

Description

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

Comment 1

5 years ago
carrie, please attach your spec here once its available
Blocks: 903304
blocking-b2g: --- → koi?
Flags: needinfo?(cawang)
(Reporter)

Updated

5 years ago
Blocks: 911681
Carrie, could you also link the user story?

Updated

5 years ago
blocking-b2g: koi? → koi+
Hi Neo,

Please help to clarify the issue. Thanks!

(In reply to styang from comment #2)
> Carrie, could you also link the user story?
Flags: needinfo?(cawang) → needinfo?(nhsieh)
Assignee: nobody → gduan
Created attachment 801597 [details]
spec-Lock screen-130909 .pdf

Attached is the spec for lockscreen.
Created attachment 801601 [details]
spec-Home Screen-130909.pdf

Attached is the spec for homescreen.
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.
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.....
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].
(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! :)
Created attachment 803599 [details]
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.
(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.
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 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
Attachment #803599 - Flags: review?(alive)
Comment on attachment 803599 [details]
PR to master

Where's the window manager transition change?
And use feedback next time for WIP.
Attachment #803599 - Flags: review?(alive)
(Reporter)

Updated

5 years ago
Blocks: 917228
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.
Flags: needinfo?(alive)
offline discussion.
Flags: needinfo?(alive)
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.
Attachment #803599 - Flags: review?(alive)
Comment on attachment 803599 [details]
PR to master

See comments. and Please try to have unit tests.
Attachment #803599 - Flags: review?(alive)
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!
Attachment #803599 - Flags: review?(alive)
Comment on attachment 803599 [details]
PR to master

Great work, r=me, thanks for the patience.
Attachment #803599 - Flags: review?(alive) → review+
Open bug 918272 for animation.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(nhsieh)
Resolution: --- → FIXED

Comment 23

4 years ago
Created attachment 811774 [details]
LockScreen_20130923.zip

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

Comment 24

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

Thanks,
Juwei
Uplifted 0dedb5b3789afc638a0c7c67652937fcb30e77d2 to:
v1.2: 812700755f4556fb44325693fa35cb29a8fa9f11
status-b2g-v1.2: --- → fixed
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?
You need to log in before you can comment on or make changes to this bug.