Update network triage docs.

In particular, replace about:net-internals with
chrome://net-export, add link to end-user instructions to
chrome://net-export itself, add a link to internal chrome network
crash page, and slightly update instructions.

Bug: None
Change-Id: I8ce872f1874ca632c7a1417fb9727fe4e4131778
Reviewed-on: https://chromium-review.googlesource.com/964943
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544402}

components/net_log/resources/net_export.html

@@ -44,6 +44,9 @@
       <div class="section-container">
         Click the button to start logging future network activity to a file on
         disk.
+        <a href="https://dev.chromium.org/for-testers/providing-network-details"
+           target="_blank">
+        See the Chromium website for more detailed instructions.</a>
       </div>
 
       <div class="outline-box">

net/docs/bug-triage-suggested-workflow.md

@@ -21,7 +21,7 @@
   trace in the bug, so no one else has to look up the crash stack from the ID.
     * If there's just a blank form and a crash ID, just ignore the bug.
 
-* If network causes are possible, ask for a net-internals log (If it's not a
+* If network causes are possible, ask for a net-export log (If it's not a
   browser crash) and attach the most specific internals-network label that's
   applicable.  If there isn't an applicable narrower component, a clear owner
   for the issue, or there are multiple possibilities, attach the
@@ -50,7 +50,7 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
 ## Investigating component=Internals>Network bugs
 
 * Note that you may want to investigate Needs-Feedback bugs first, as
-  that may result in some bugs being added to this list.  
+  that may result in some bugs being added to this list.
 
 * It's recommended that while on triage duty, you subscribe to the
   Internals>Network component (but not its subcomponents). To do this, go
@@ -90,7 +90,7 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
 * If it may be a network bug, attach additional possibly relevant component if
   any, and continue investigating.  Once you either determine it's a
   non-network bug, or figure out accurate more specific network components, your
-  job is done, though you should still ask for a net-internals dump if it seems
+  job is done, though you should still ask for a net-export dump if it seems
   likely to be useful.
 
 * Note that Chrome-OS-specific network-related code (Captive portal detection,
@@ -105,11 +105,10 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
       user.
     * Try to reproduce locally.  If you can, and it's a regression, use
       src/tools/bisect-builds.py to figure out when it regressed.
-    * Ask more data from the user as needed (net-internals dumps, repro case,
-      crash ID from about:crashes, run tests, etc).
-    * If asking for an about:net-internals dump, provide this link:
+    * Ask more data from the user as needed (net-export dumps, repro case,
+      crash ID from chrome://crashes, run tests, etc).
+    * If asking for a chrome://net-export dump, provide this link:
       https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.
-      Can just grab the link from about:net-internals, as needed.
 
 * Try to figure out what's going on, and which more specific network component
   is most appropriate.
@@ -119,10 +118,9 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
   strongly suspect CLs.
 
 * If you are having trouble with an issue, particularly for help understanding
-  net-internals logs, email the public net-dev@chromium.org list for help
+  net-export logs, email the public net-dev@chromium.org list for help
   debugging.  If it's a crasher, or for some other reason discussion needs to
-  be done in private, use chrome-network-debugging@google.com.  TODO(mmenke):
-  Write up a net-internals tips and tricks docs.
+  be done in private, use chrome-network-debugging@google.com.
 
 * If it appears to be a bug in the unowned core of the network stack (i.e. no
   subcomponent applies, or only the Internals>Network>HTTP subcomponent
@@ -184,7 +182,7 @@ As an alternative to the above, you can use [Eric Roman's new crash
 tool](https://ericroman.users.x20web.corp.google.com/www/net-crash-triage/index.html)
 (internal link).  Note that it isn't a perfect fit with the triage
 responsibilities, specifically:
-  
+
 * It's only showing Windows releases; Android, iOS, and WebView are
   usually different, and Mac is sometimes different.
 * The instructions are to look at the latest canary which has a days
@@ -192,7 +190,7 @@ responsibilities, specifically:
   than one canary into the past, and hence not visible on the tool.
 * Eric's tool filters based on files in "src/net" rather than looking
   for magic signature's including the string "net::" ("src/net" is
-  probably the better filter).    
+  probably the better filter).
 
 ## Investigating crashers
 

net/docs/bug-triage.md

@@ -30,20 +30,20 @@ uniform, predictable two day commitment for all triagers.
 
 ### Required:
 
-* Identify new network bugs on the bug tracker.  All Unconfirmed issues filed
-  during your triage rotation should be scanned, and, for suspected network
-  bugs, a network component assigned and an about:net-internals log requested.
-  A triager is responsible for looking at bugs reported from noon PST / 3:00 pm
-  EST of the last day of the previous triager's rotation until the same time on
-  the last day of their rotation.  Once you've assigned a bug to a component,
-  mark it Untriaged, so other triagers sorting through Unconfirmed bugs won't
-  see it. 
-  
-    * For desktop bugs, ask for a net-internals log and give the user a link to
-      https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
-      (A link there appears on about:net-internals, for easy reference) for
-      instructions.  On mobile, point them to about:net-export.  In either case,
-      attach the Needs-Feedback label.
+* Identify new network bugs on the bug tracker, looking at [this issue tracker
+  query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed&sort=-id&num=1000).
+
+  * All Unconfirmed issues filed during your triage rotation should be scanned,
+    and, for suspected network bugs, a network component assigned and a
+    chrome://net-export/ log requested.  Suggested text: "Please collect and
+    attach a chrome://net-export log. Instructions can be found here:
+    https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details".
+    A link to the instructions appears on net-export, for easy reference.
+    When asking for a log or more details, attach the Needs-Feedback label.
+
+  * A triager is responsible for looking at bugs reported from noon PST /
+    3:00 pm EST of the last day of the previous triager's rotation until the
+    same time on the last day of their rotation.
 
 * Investigate UMA notifications.
 
@@ -51,17 +51,17 @@ uniform, predictable two day commitment for all triagers.
       sent to   chrome-network-debugging@google.com.  Triagers should subscribe
       to this list.  When an alert fires, the triager should determine if the
       alert looks to be real and file a bug with the appropriate label if so.
-      Note that if no label more specific than Internals>Network is appropriate,
-      the responsibility remains with the triager to continue investigating the
-      bug, as above.
-      
+      Note that if no label more specific than Internals>Network is
+      appropriate, the responsibility remains with the triager to continue
+      investigating the bug, as above.
+
     * The triager is responsible for looking at any notification previous
       triagers did not, so when an issue is investigated, the person who did
       so should respond to chrome-network-debugging@google.com with a short
       email, describing their conclusions.  Future triagers can then use the
       fact an alert was responded to as an indicator of which of them need
       to be followed up on.  Alerts fired before the beginning of the
-      previous triager's rotation may be ignored. 
+      previous triager's rotation may be ignored.
 
 * Investigate [Unconfirmed / Untriaged Internals>Network issues that don't belong to a more specific network component](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified),
   prioritizing the most recent issues, ones with the most responsive reporters,
@@ -82,8 +82,8 @@ uniform, predictable two day commitment for all triagers.
       due to the way the bug report wizard works, a lot of bugs incorrectly end
       up with the network component.
 
-    * The issue is assigned to an appropriate owner, and make sure to mark it
-      as "assigned" so the next triager doesn't run into it.
+    * The issue is assigned to an appropriate owner.  Make sure to mark it as
+      "assigned" so the next triager doesn't run into it.
 
     * If there is no more specific component for a bug, it should be
       investigated by the triager until we have a good understanding of the
@@ -118,6 +118,10 @@ uniform, predictable two day commitment for all triagers.
 
     * Make sure to check for new crashes on all platforms, not just Windows.
 
+    * [go/chromenetcrash](https://goto.google.com/chromenetcrash) has a list
+      of net crashes by version, though makes it more difficult to tell if a
+      crash makes up a significant portion of all Chrome crashes.
+
 ### Best Effort (As you have time):
 
 * Investigate old bugs, and bugs associated with Internals>Network
@@ -125,8 +129,8 @@ uniform, predictable two day commitment for all triagers.
 
 * Investigate unowned and owned but forgotten net/ crashers that are still
   occurring (As indicated by
-  [go/chromecrash](https://goto.google.com/chromecrash)), prioritizing frequent
-  and long standing crashers.
+  [go/chromenetcrash](https://goto.google.com/chromenetcrash)), prioritizing
+  frequent and long standing crashers.
 
 * Close obsolete bugs.
 
@@ -137,4 +141,4 @@ See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network
 and non-network bugs.
 
 See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for
-some help on getting started with about:net-internals debugging.
+some help on getting started with chrome://net-internals debugging.

net/docs/crash-course-in-net-internals.md

-# A Crash Course in Debugging with about:net-internals
+# A Crash Course in Debugging with chrome://net-internals
 
 This document is intended to help get people started debugging network errors
-with about:net-internals, with some commonly useful tips and tricks.  This
+with chrome://net-internals, with some commonly useful tips and tricks.  This
 document is aimed more at how to get started using some of its features to
 investigate bug reports, rather than as a feature overview.
 
@@ -10,9 +10,9 @@ It would probably be useful to read
 
 # What Data Net-Internals Contains
 
-about:net-internals provides a view of browser activity from net/'s perspective.
-For this reason, it lacks knowledge of tabs, navigation, frames, resource types,
-etc.
+chrome://net-internals provides a view of browser activity from net/'s
+perspective.  For this reason, it lacks knowledge of tabs, navigation, frames,
+resource types, etc.
 
 The leftmost column presents a list of views.  Most debugging is done with the
 Events view, which will be all this document covers.
@@ -23,13 +23,13 @@ single, global, ChromeNetLog object.  This includes both incognito and
 non-incognito profiles, among other things.  The Events view only shows events
 for the period that net-internals was open and running, and is incrementally
 updated as events occur.  The code attempts to add a top level event for
-URLRequests that were active when the about:net-internals tab was opened, to
+URLRequests that were active when the chrome://net-internals tab was opened, to
 help debug hung requests, but that's best-effort only, and only includes
 requests for the current profile and the system URLRequestContext.
 
 The other views are all snapshots of the current state of the main
 URLRequestContext's components, and are updated on a 5 second timer.  These will
-show objects that were created before about:net-internals was opened.
+show objects that were created before chrome://net-internals was opened.
 
 # Events vs Sources
 
@@ -165,7 +165,7 @@ should generally ignore those, and look for a more interesting one.
 This is often useful in finding hung or slow requests.
 
 For a list of other filter commands, you can mouse over the question mark on
-about:net-internals.
+chrome://net-internals.
 
 Once you locate the problematic request, the next is to figure out where the
 problem is -- it's often one of the last events, though it could also be related