1023046 - [App2App Transition] Do back transition if we are switched to an existing app

Status: RESOLVED WONTFIX

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

Description

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

This is inspired from https://bugzilla.mozilla.org/show_bug.cgi?id=1016280#c18

Currently we always use left-out-right-in transition between app to app transitions. But since we are introducing sheets and old sheets are left side/new sheets are right side, I think we could improve this by change the transition when the nextApp is not a new created App in AppWindowManager.

Comment 2

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

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

proposed fix v1: Change the app to app transition according to its serial number ordering.

Comment 3

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

Comment on attachment 8437430 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20261

Please rewrite the :? operators into proper if..else blocks.

I believe you have proper unit test in place to keep the logic unchanged.

Comment 4

[Tiffanie Shakespeare [:tif]]

Nominating as a blocker. Having the incorrect transition makes navigating settings super confusing and can cause disorientation when then user is more than one level deep in settings.

Comment 5

[Jason Smith [:jsmith]]

A video will help understand the severity here.

Comment 6

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

https://github.com/mozilla-b2g/gaia/commit/67b1679554cc517a5213aa2a746de26afe977eb8

Comment 7

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 8437430 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20261

I am kind-of worried about if the transition is correct for the following case,
 1. Launch settings app first.
 2. Press [Home] button to go back to homescreen.
 3. Launch Message app and press the upper right [...] button.

-> This will lead to settings app and the transition will be left to right after this change.

 4. Besides, if your press [X] button to close "Messaging Settings", the transition would be also "left-to-right".

Tiffanie, could you please help take a look at the above scenario?
Thanks.

Comment 8

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

(In reply to Rudy Lu [:rudyl] from comment #7)
> Comment on attachment 8437430 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/20261
> 
> I am kind-of worried about if the transition is correct for the following
> case,
>  1. Launch settings app first.
>  2. Press [Home] button to go back to homescreen.
>  3. Launch Message app and press the upper right [...] button.
> 
> -> This will lead to settings app and the transition will be left to right
> after this change.

The only problem I saw is the settings has a right-to-left transition from main panel to message panel,
but this is because it doesn't support activity very well. User shouldn't see the main panel.

> 
>  4. Besides, if your press [X] button to close "Messaging Settings", the
> transition would be also "left-to-right".
> 
> Tiffanie, could you please help take a look at the above scenario?
> Thanks.

This is a losing part in app_window.js when activity is done, I am going to file another bug to fix it.

Comment 9

[Tiffanie Shakespeare [:tif]]

Hey Gordon! Can you help out with the behaviour mentioned in comment #7. It's definitely funky.

Comment 10

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

So the proposed fix would be:
Decide the app to app transition according to the ordering in the sheet stack.
If the opening app is elder than current app, it comes from left;
if the opening app is newer than current app, it comes from right.

Comment 11

[bhavana bajaj [:bajaj]]

Alive, can you please help with a video to understand the user impact and severity of not fixing this?

Comment 12

[Rob MacDonald [:robmac]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #10)
> So the proposed fix would be:
> Decide the app to app transition according to the ordering in the sheet
> stack.
> If the opening app is elder than current app, it comes from left;
> if the opening app is newer than current app, it comes from right.

Hi Alive...

Here's the reference from page 20 of the spec, which is located in box at https://mozilla.box.com/s/ehnzpk0dnqdwk6qtf6x5

--- start snippet ---
Apps are ordered based on when they were launched. The most recently launched app is placed on the top (far right) of the sheet stack.

An app is considered "launched" when...
- The user taps on the app icon on the home grid
- The user taps on the app preview in the task manager 
- The user taps on a notification in the utility tray
- An app launches another app (excluding sub-tasks).
In app navigation does not affect the order of sheets within the stack. 

--- end snippet ---

So, if app A launches app B, app B is moved to the top (far right) of the sheet stack... regardless of whether it's been launched previously. So app B slides in from the right edge of the screen moving left.

Subtasks are an exception and, rather than spawning a new sheet, exist on top of the existing sheet. This is described in page 13 of the spec. The transition for subtasks should be the same as an activity, although this too is inconsistent currently across apps. Currently activities slide in from the bottom, but the intent is to have these fade in instead.

Generally app-specific settings are supposed to be treated as a view within the app and not contained within the general settings which are meant to be platform wide. So linking to settings in this instance seems to be a big exception to the pattern. Whether we want to treat this as a subtask (keep it on the same sheet) or as a link to a new app (new sheet) is up to the ux owner for messaging.

NI me if you have any questions. I'll be reviewing similar issues on Friday and likely arrange a meeting early next week to discuss.

- Rob

Comment 13

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: youTube link

Please take a look at this example,
http://youtu.be/YGzcOpZ27tk

from 5 second, you could see the transition is right-to-left even when you're pressing a [Back] button.
(https://www.youtube.com/watch?v=YGzcOpZ27tk&feature=youtu.be&t=5s)

Comment 14

[Jason Smith [:jsmith]]

Alive - Can you backout the landed patch & rework it against Rob's requirements above?

Comment 15

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

I guess we (UX/dev/bug filer/PM/QA) are not at the same page here.
UX doesn't provide any new requirement in comment 12.

The fix of this bug is trying to give a possible workaround to fix comment 13 but comment 12 doesn't fix comment 13. System app has no reason to know "why settings launches another app?" but only know "settings app is foreground and another app is launched".

In the case it seems UX's app to app case is satisfied and it just causes this bug.

Comment 16

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

(In reply to Jason Smith [:jsmith] from comment #14)
> Alive - Can you backout the landed patch & rework it against Rob's
> requirements above?

I can but I want UX to understand what's the really problem here.

Comment 17

[Rob MacDonald [:robmac]]

Hi Alive - Sorry I understood the issue earlier. Here's a snippet from the email I just sent as it's relevant to this bug...

Talking to Etienne this morning, he has proposed using an inline activity. Although the window will fade in on top (as opposed to coming in from the right), this way at least it will remain as part of the parent app in sheets and app switcher. Alive, does this make sense in your view? Checking my assumptions, would this eliminate the display of the app launch screen when loading the “view”? And, would the activity be retained when the user returns to settings?

- Rob

Comment 18

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

(In reply to Rob MacDonald [:robmac] from comment #17)
> Hi Alive - Sorry I understood the issue earlier. Here's a snippet from the
> email I just sent as it's relevant to this bug...
> 
> Talking to Etienne this morning, he has proposed using an inline activity.
> Although the window will fade in on top (as opposed to coming in from the
> right), this way at least it will remain as part of the parent app in sheets
> and app switcher. Alive, does this make sense in your view? Checking my
> assumptions, would this eliminate the display of the app launch screen when
> loading the “view”? And, would the activity be retained when the user
> returns to settings?
> 
> - Rob

For ringtone case this works but for keyboard cases, we cannot ask certain keyboard activity because the activity name is shared among all keyboard apps. So that's why they use a hack to launch the keyboard app directly to access the setting page.

Comment 19

[Tiffanie Shakespeare [:tif]]

Comment on attachment 8437430 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20261

clearing my ui-review flag. Looks like Rob has a handle on the situation and it's been sorted out.

Comment 20

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

Why are we reopening a bug without backing out a patch? IMHO this should be closed and any subsequent fix should be in another bug.

Etienne, Alive is PTO this week. Could you fix this inconsistency?

Comment 21

[Etienne Segonzac (:etienne)]

I've opened a backout pull request https://github.com/mozilla-b2g/gaia/pull/20972

This fixes the weird double transition issue mentioned in Comment 7. And fixes the issue where we're showing the app coming from the left but actually moving it on top of the stack...

Regarding the keyboard transition issue from Comment 13, I'm not sure there's much UX can do to "formalize the hack".

While waiting for the keyboard settings to actually live in the settings app we can workaround by going to the previous app (instead of the homescreen) when a app with role=input does a window.close.

Thought?

Comment 22

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

The reason I ask for a resolution here is because I am totally confused what is considered as a blocker here. 

The patch never made it's way to 2.0 branch, so the quirks mentioned in comment 7 shouldn't be a blocker for 2.0. So the only explanation here is that this late feature requested by UX somehow made it's way into 2.0+ blocker after FC.

Are we really blocking on feature now? Really? Rob, could you shed some light here?

(In reply to Etienne Segonzac (:etienne) from comment #21)
> I've opened a backout pull request
> https://github.com/mozilla-b2g/gaia/pull/20972
> 
> This fixes the weird double transition issue mentioned in Comment 7. And
> fixes the issue where we're showing the app coming from the left but
> actually moving it on top of the stack...

If comment 7 is considered as an issue so bad that this patch shouldn't be living in master, let's backout the patch.

> Regarding the keyboard transition issue from Comment 13, I'm not sure
> there's much UX can do to "formalize the hack".
> 
> While waiting for the keyboard settings to actually live in the settings app
> we can workaround by going to the previous app (instead of the homescreen)
> when a app with role=input does a window.close.
> 
> Thought?

Agree. For the keyboard settings I agree we should pile hacks on top of one another since we know it will be removed when bug 1020063 lands.

Comment 23

[howie [:howie]]

This bug is not a blocker, whether it's based on Comment 7 , Comment 13 , or from the very initial description that "we could improve". It's an enhancement work, not a regression nor a major defect of feature work that blocks the whole release.

Comment 24

[Etienne Segonzac (:etienne)]

The backout landed: https://github.com/mozilla-b2g/gaia/commit/a91d3ccfea50ee7fb4a8dbef76f3027151359d93
The sms use case is now back to-spec, only the keyboard one remains.

Since this is not blocking we might just wait for bug 1020063, the status looks promising :)

Comment 25

[Jason Smith [:jsmith]]

(In reply to howie [:howie] from comment #23)
> This bug is not a blocker, whether it's based on Comment 7 , Comment 13 , or
> from the very initial description that "we could improve". It's an
> enhancement work, not a regression nor a major defect of feature work that
> blocks the whole release.

It's a major defect of feature work. Sheets workflows is a requirement of 2.0 & Haida.

Comment 26

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

Deassign myself.

Comment 27

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #25)
> (In reply to howie [:howie] from comment #23)
> > This bug is not a blocker, whether it's based on Comment 7 , Comment 13 , or
> > from the very initial description that "we could improve". It's an
> > enhancement work, not a regression nor a major defect of feature work that
> > blocks the whole release.
> 
> It's a major defect of feature work. Sheets workflows is a requirement of
> 2.0 & Haida.

Meant to leave this on the nom queue, not + it.

Comment 28

[Rob MacDonald [:robmac]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #22)
> The reason I ask for a resolution here is because I am totally confused what
> is considered as a blocker here. 
> 
> The patch never made it's way to 2.0 branch, so the quirks mentioned in
> comment 7 shouldn't be a blocker for 2.0. So the only explanation here is
> that this late feature requested by UX somehow made it's way into 2.0+
> blocker after FC.
> 
> Are we really blocking on feature now? Really? Rob, could you shed some
> light here?
> 

Based on today's build, here's my understanding of the issues with the current keyboard implementation from the ux perspective:

1) The transitions to the keyboard settings are not the same as a view transition
2) Hitting the back button from within keyboard settings triggers a new app transition, which is correct in other circumstances, but not this one as we're pretending the keyboard app is part of the settings app.
3) Settings and keyboard are two separate apps within the task switcher and edge gestures.

The core of the problem is that we have an app pretending to be a view within the settings app. So technically the transitions and multi-tasking are working to spec if we were talking about two different apps. But, since we're faking a single settings app, we run into awkward transitions and unexpected behaviours in multi-tasking. And, while we managed to mitigate this for ringtones and messaging, it seems the keyboard is more challenging because it is shared across keyboard apps. 

Although these issues are less than optimal, at this late stage, the key from my perspective is that we're not blocking any functionality or creating any severe usability issues. Assuming I've accurately captured the issues above, and that a fix is in the works for 2.1, I personally would not block or delay release for this. However, since this is also a keyboard issue, I'll flag Mike, the ux owner for keyboard, for his feedback as well.

Comment 29

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

Omega, would you like to make a call on behave of Mike while he PTO? Thanks.

Comment 30

[Jason Smith [:jsmith]]

I'll kick this out of the nom queue then per comment 28.

Comment 31

[Omega Feng [:Omega] [:馮於懋]]

After discussion, the ultimate solution seems to be embedded iframe, so let's solve this when nested oop is ready.
And, from this issue, I learned that if we have to use a workaround next time, we should consider more about the regression, and plan the ultimate solution immediately, to prevent the similar issue like this one.

Comment 32

[BMO Automation]

Firefox OS is not being worked on