Back button behavior should be consistent among Android apps, Chrome apps, and Browser. |
|||||||
Issue description(This issue is forked from issue 807521 to discuss general behaviors). In tablet mode, we show a back button on the shelf. It basically sends a back event to the active window. However, when there is no back stack in the active window, default behaviors are different depending on application types. 1) Android apps The window closes by default. Some apps implement different behaviors. For instance, Chrome for Android goes minimized state. 2) Chrome apps The window remains open. The back button is ignored unless the app handles BrowserBack event. 3) Chrome browser The window remains open. The back button is ignored unless there is back stack on the history. It should be better to have consistent behaviors among application types. To make Chrome apps / Chrome browser behavior similar to Android apps, there are some options I can think of. Option 1: Close Chrome apps / Chrome browser when there is no back stack. Option 2: Minimize Chrome apps / Chrome browser when there is no back stack. At this moment, I'm leaning option 2. Reason: Android apps are closed by default on back button, but users can still easily access to the closed apps from the recents button (the square button on bottom-right). It is not the case for Chrome OS, as we show only active windows in task switcher. By enabling the back button, users will accidentally close apps more frequently. Keeping apps in minimized state will help the user go back to the recent app. If we choose option 2, it can also make sense to minimize Android apps on back button instead of closing them, to be consistent with Chrome apps/browser and make recent apps easier to access from task switcher. It consumes more memory, though. omrilio@, WDYT?
,
Feb 20 2018
Sorry, was OOO. ChromeOS and Android actually behave similarly on "recents" (overview), we both only show the active apps. However, the whole model of an active app is completely different at the moment between Android and ChromeOS. My thinking is that in the long run we will want to be more opinionated on each app and decide which ones do Option 1, as we have better management for apps states. For now, I agree with you that Option 2 is the best approach. Thank you!
,
Mar 19 2018
,
Mar 23 2018
,
Mar 29 2018
I'd like to punt the remaining work of this issue to M-68 to prioritizing ZipArchiver to be shipped with M-67.
,
Apr 11 2018
In the latest canary, the back button in the tablet mode does nothing for Google Keep, Text, and Secure Shell (these are pre-installed Chrome apps). This bug (issue 812564) is about adding a generic behavior for apps that don't handle BrowserBack event, and got punted to M68. Tom, if you want to fix the back button issue with Keep in M67, it can be done by adding a fix to the Keep code. https://chromium-review.googlesource.com/c/chromium/src/+/940743 illustrates how this issue was fixed in Files app.
,
Apr 11 2018
+1! I'd love to have a consistent story here if possible.
,
Apr 11 2018
+raymes for Secure Shell. Please see Comment 6 for the background. This bug (issue 812564) got punted to M68, and there is a risk of getting punted again, so handling the back button event per app is safer if we want to fix the issue with the pre-installed apps.
,
Apr 11 2018
Bug for Keep Chrome app: b/77883557
,
May 28 2018
Just confirmed that the back button now works with Keep Chrome app. Thank you for fixing! Text app and Secure Shell still do not handle the back button.
,
Jan 16
(6 days ago)
Issue 920842 has been merged into this issue. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by fukino@chromium.org
, Feb 20 2018