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

Issue 713828 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocking:
issue 697259



Sign in to add a comment

The "Send Feedback" button on the Aw Snap/Sad tab should be reset to "Reload" after a successful page load

Project Member Reported by yyushkina@chromium.org, Apr 20 2017

Issue description

Chrome Version: 57.0.2987.133 (64-bit)
OS: macOS Sierra 10.12.4, also confirmed on ChromeOS and Windows

What steps will reproduce the problem?
(1) Start a new Chrome session. Go to chrome://crash. Observe reload button. 
(2) Click "Reload". Go to another page (any page). 
(3) Go to chrome://crash again. 

What is the expected result? Observe "Reload" button.

What happens instead? Observe "Send Feedback" button.

The Send Feedback button (and the associated Send Feedback strings) should only be shown upon a second failed reload of the same URL. If there has been a successful load of the URL after the initial presentation of the SadTab UI, any subsequent failure should be treated as an initial failure (i.e. successfully loading the URL resets the SadTab process). In the case where the user reloads the crashing URL via a mechanism other than the Reload button, this should be considered a repeated page load, just as the user tapped the Reload button.

The guiding principle behind these display rules is to try and give the user a Reload button if we think it’s worth trying a reload, and a Feedback button if we believe that a reload is unlikely to fix the user’s issue.  

 

Comment 1 by wfh@chromium.org, Apr 20 2017

so the feedback button should only appear if it's the result of a direct navigation from pushing the reload button? Perhaps we can keep some kind of tab state instead of global state, if that's the desired behavior...?
No. The Send Feedback button should appear from any reload, whether from the button or through other means (e.g. clicking on the omnibox and pressing enter, reload icon in the omnibar, etc). However if the reload is successful and we show a non-crashing page we reset, so that if we crash again in the same session we see the Reload button.
Cc: pamg@google.com
Cc: -wfh@chromium.org yyushkina@chromium.org
Owner: wfh@chromium.org

Comment 5 by wfh@chromium.org, May 17 2017

We decided after some discussion that we would have a minimum time between sad tabs of 10 seconds, if a sad tab has been shown within 10 seconds then the "feedback" one is shown otherwise the "reload" one is shown. We feel this meets the same objective as specific page tracking but with considerably less code complexity.

Comment 6 by wfh@chromium.org, May 18 2017

Manual test for this bug:

 - Load chrome and simulate a crash using chrome://crash.
 - Verify blue button is 'reload'.
 - Within 10 seconds simulate another crash using chrome://crash.
 - Verify blue button is 'send feedback'.
 - Wait an additional 20 seconds and simulate another crash using chrome://crash.
 - Verify blue button is now 'reload'.
Project Member

Comment 7 by bugdroid1@chromium.org, May 19 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9a40db46670d1c37111c0010d36fc290566eaf0

commit c9a40db46670d1c37111c0010d36fc290566eaf0
Author: wfh <wfh@chromium.org>
Date: Fri May 19 15:54:02 2017

Show feedback button on sad tab if sad tab has shown recently.

BUG= 713828 
TEST=manual, see bug.

Review-Url: https://codereview.chromium.org/2885143009
Cr-Commit-Position: refs/heads/master@{#473204}

[modify] https://crrev.com/c9a40db46670d1c37111c0010d36fc290566eaf0/chrome/browser/ui/sad_tab.cc

Comment 8 by wfh@chromium.org, May 19 2017

Status: Fixed (was: Assigned)
Blocking: 697259
Status: Verified (was: Fixed)
Verified on ChromeOS 9581.0.0, 60.0.3107.0 using steps from c#6 

Sign in to add a comment