Update net triage instructions.

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

 # A Crash Course in Debugging with about: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
 document is aimed more at how to get started using some of its features to
 investigate bug reports, rather than as a feature overview.
 
-It would probably be useful to read [life-of-a-url-request.md](
-life-of-a-url-request.md) before this document.
+It would probably be useful to read
+[life-of-a-url-request.md](life-of-a-url-request.md) before this document.
 
 # 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.
 
 The top level network stack object is the URLRequestContext.  The Events View
 has information for all Chrome URLRequestContexts that are hooked up to the
 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 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.  Most
 debugging is done with the Events view (which will be all this document
 covers), but it's good to be aware of this distinction.
 
 # Events vs Sources
 
 The Event View shows events logged by the NetLog.  The NetLog model is that
 long-lived network stack objects, called sources, emit events over their
-lifetime.  Some events have a beginning and end point (during which other
-subevents may occur), and some only occur at a single point in time.  Generally
-only one event can be occuring for a source at a time.  If there can be multiple
-events doing completely independent thing, the code often uses new sources to
-represent the parallelism.
+lifetime.  When looking at the code, a "BoundNetLog" object contains a source
+ID, and a pointer to the NetLog the source emits events to.  Some events have a
+beginning and end point (during which other subevents may occur), and some only
+occur at a single point in time.  Generally only one event can be occuring for a
+source at a time.  If there can be multiple events doing completely independent
+thing, the code often uses new sources to represent the parallelism.
 
 "Sources" correspond to certain net objects, however, multiple layers of net/
 will often log to a single source.  Here are the main source types and what they
 include (Excluding HTTP2 [SPDY]/QUIC):
 
 * URL_REQUEST:  This corresponds to the URLRequest object.  It includes events
 from all the URLRequestJobs, HttpCache::Transactions, NetworkTransactions,
 HttpStreamFactoryImpl::Requests, HttpStream implementations, and
 HttpStreamParsers used to service a response.  If the URL_REQUEST follows HTTP
 redirects, it will include each redirect.  This is a lot of stuff, but generally
@@ skipping 40 matching lines @@
 code or the exact URL of the resource that won't load, you can just search for
 it.  If it's an upload, you can search for "post", or if it's a redirect issue,
 you can search for "redirect".  However, you often won't have much information
 about the actual problem.  There are two filters in net-internals that can help
 in a lot of cases:
 
 * "type:URL_REQUEST is:error" will restrict the list to URL_REQUEST object with
 an error of some sort (red background).  Cache errors are often non-fatal, so
 you should generally ignore those, and look for a more interesting one.
 
-* "type:URL_REQUEST sort:duration" will show the lonest-lived requests (as of
-when about:net-internals was opened) first.  This is often useful in finding
-hung or slow requests.
+* "type:URL_REQUEST sort:duration" will show the longest-lived requests first.
+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.
 
 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
 to response or request headers.  You can use "source_dependency" links to drill
 down into other related sources, or up from layers below URL_REQUEST.
 
 You can use the name of an event to search for the code responsible for that
@@ skipping 59 matching lines @@
 things like HSTS redirects (URLRequestRedirectJob), AppCache, ServiceWorker,
 etc.  These generally don't log as much information, so it can be tricky to
 figure out what's going on with these.
 
 * Non-HTTP requests also appear in the log, and also generally don't log much
 (blob URLs, chrome URLs, etc).
 
 * Preconnects create a "HTTP_STREAM_JOB" event that may create multiple
 CONNECT_JOBs (or none) and is then destroyed.  These can be identified by the
 "SOCKET_POOL_CONNECTING_N_SOCKETS" events.