New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 711380 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Feature



Sign in to add a comment

"Close all tabs" subject to unintended selection, no undo or session restore

Reported by dredmorb...@gmail.com, Apr 13 2017

Issue description

Steps to reproduce the problem:
1. Think you be doing something with tabs.
2. Inadvertently manage a long press on 'x', then drift to the "close all tabs" now open immediately below current tap point.
3. Lose hours, days, weeks, or months worth of curated content.

What is the expected behavior?
User state should not be inadvertently and irrevocably lost through a trivially-unintentionally-activated application element.

State-destruction actions should be resistant to inadvertent activation, confirm action, and offer an undo capability.

What went wrong?
2-3 months of user state lost as a result of an unsteady hand late in the day on a laggy tablet with craptacular touch registration at the best of times.

Did this work before? N/A 

Chrome version: 53.0.2785.124  Channel: n/a
OS Version: 5.0.2
Flash Version: 

Chromium failed to follow its own suggestions for a sane UI.  See @dtrainor's comments:  https://bugs.chromium.org/p/chromium/issues/detail?id=268157#c46

"It's a really destructive option so putting it in the main menu is scary (even if we could convince UX and tie in undo). Long press sounds interesting but I don't know what would be discoverable enough."

So far as I can tell, there's no "undo" option.

Compounding factors:

1. Android has a tremendous problem distinguishing "click" from "drag".  Or in this case "long touch" from "drag".

2. Touchscreen device position registration is shakey at best.

I'm out about 2-3 months of accumulated state.

The meta-problem is that Chrome/Android has terrible state and tab management.  It's painfully difficult to navigate or search tabs, so tab debt accrues:
https://bugs.chromium.org/p/chromium/issues/detail?id=268157#c14

In lieu of solving that straight off, not fucking blowing away months of user work, and offering reasonable mechanisms for restoring _prior browsing state_ would be useful.

"Recent tabs" doesn't begin to address this.

"History" shows URLs _in the order they were opened_, which has little if any relationship to the state of tabs within a browsing session.  It's not possible to select sets of URLs for bulk action (e.g., "open selected URLs in new tabs).

Move the fucking "close all tabs" item elsewhere, or move the activation button *somewhere other than immediately next to the current touch point*.  Require a verification *someplace distinctly elsewhere on the screen* for the action.  Offer an "undo" capability.

Implementing "close all tabs" as "reduce to a single blank tab" rather than "delete all tabs and close app" would offer a better option for prompting for an undo/restore option.  (Or, possibly, a "clear full history").  Alternatively, a "restore previous session" option would address the undo requirement.  And probably should have been the initial design.

This user is less than gruntled.

https://plus.google.com/104092656004159577193/posts/LXYChDt6ts1

Did this work before? N/A 

Chrome version: 56.0.2924.87  Channel: n/a
OS Version: 
Flash Version: 

See #658500

The activation control is the problem. Fix that.

The suggested recovery methods do not recover as I've tested them.
 

Comment 1 by mmenke@chromium.org, Apr 19 2017

Components: -UI UI>Browser>TabStrip
Cc: pnangunoori@chromium.org
Labels: Needs-triage-Mobile Triaged-Mobile Needs-Feedback
@dredmorbius -- Could you please update your Chrome to latest stable version #62.0.3202.84. Upon closing tab you can use "Undo" option to recover the closed tabs.

Thanks in advance.
Does this apply to Incognito mode as well?

How about moving the damned control?

And:  given that I'm still trying to manage-down tabs *from last fucking
April*, odds of my testing this out are somewhere in the slim-to-nil
category.  You've dug yourself several holes here, and a massive one
involves my trusting you're not going to fuck over my user state.  Again.

Particularly given that that happens somewhere between hourly and daily.

That's for one user.  Multiply x Google Scale for net impacts.
Project Member

Comment 4 by sheriffbot@chromium.org, Nov 22 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I can confirm, BTW, that I'm at v. 62.0.3202.84, checking via the Android
Settings => Applications => All Apps screen.

Again:  Far too much user state to casually test this.
Labels: Needs-Feedback
@dredmorbius -- Thanks for providing the reply. It is the Chrome feature that Undo option is not available for tabs opened in incognito mode. It can be taken as the Feature Request if you want.

If it is not the case, kindly provide the screencast of the actual issue faced by you. It would be helpful for us to triage the issue.

Thanks in advance.
I've described the issue in detail.

I don't have, don't know how to use, and am not interested in acquiring or learning "screencast" tools for Google's benefit.

If a feature which can, has, is, will be, *** and in Google's own discussion of why impelementing this misfeature in the way it was implemented *** can trivially cause catastrophic state loss (of tabs in an Incognito session, as you've just noted), then *MAYBE YOU SHOULDN'T BE DOING IT THAT WAY.*

Which is the motherfucking point.
Project Member

Comment 8 by sheriffbot@chromium.org, Nov 22 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
It's obvious Google has no interest or capability of resolving this issue.  How do I prevent further updates on it?  I have no further interest in this matter.

EWONTSERF
Labels: -Type-Bug Type-Feature
Status: Untriaged (was: Unconfirmed)
Marking this issue as Feature Request and changing the status to Untriaged so that the issue gets addressed.
Status: Unconfirmed (was: Untriaged)
Updated the status to 'Unconfirmed'.
Status: Untriaged (was: Unconfirmed)
*** Bulk edit ***

Setting Feature Requests as: Untriaged 

Comment 13 by donnd@google.com, Apr 28 2018

Cc: mdjones@chromium.org dtrainor@chromium.org hannahs@chromium.org
Labels: -Pri-2 Pri-3
Owner: hannahs@chromium.org
Status: Assigned (was: Untriaged)
Summarizing this feature request: move the tab "close all" button so it's less likely to be accidentally triggered.  Closing all tabs can cause a lot of user-data loss, though recent builds can bring back tabs that are not incognito.

Assigning to UX for consideration or closing (the reporter has lost patience with this issue).

Comment 14 by donnd@google.com, Apr 28 2018

Labels: android-fe-triaged
I think this only applies to tablet UI.
Project Member

Comment 15 by bugdroid1@chromium.org, Dec 3

Labels: merge-merged-mtm-exp
The following revision refers to this bug:
  https://chromium.googlesource.com/experimental/chromium/src/+/97ce8341fb8c256fd5cc24f5f9302f24b8669e48

commit 97ce8341fb8c256fd5cc24f5f9302f24b8669e48
Author: Wei-Yin Chen (陳威尹) <wychen@chromium.org>
Date: Mon Dec 03 23:53:52 2018

Longer timeout for undo closing tab

6 seconds timeout for undoing closing a single tab.
20 seconds timeout for undoing closing all tabs.

Bug: 711380, 815083
Change-Id: Id22947e5eb78a369ac24f6edb9fede49165c6520
Reviewed-on: https://chromium-review.googlesource.com/c/1356305
Reviewed-by: Yusuf Ozuysal <yusufo@chromium.org>

[modify] https://crrev.com/97ce8341fb8c256fd5cc24f5f9302f24b8669e48/chrome/android/java/src/org/chromium/chrome/browser/snackbar/undo/UndoBarController.java

Issue 918469 has been merged into this issue.

Sign in to add a comment