Merge 159156 - Extensions Docs Server: Fix headings with no IDs

chrome/common/extensions/docs/templates/intros/webRequest.html

 <p id="classSummary">
 Use the <code>chrome.webRequest</code> module to intercept, block,
 or modify requests in-flight and to observe and analyze traffic.
 </p>
 
 <h2 id="manifest">Manifest</h2>
 <p>You must declare the "webRequest" permission in the <a
   href="manifest.html">extension manifest</a> to use the web request
 API, along with <a href="manifest.html#permissions">host permissions</a>
 for any hosts whose network requests you want to access. If you want to
@@ skipping 208 matching lines @@
 <p>Depending on the event type, you can specify strings in
 <code>opt_extraInfoSpec</code> to ask for additional information about the
 request. This is used to provide detailed information on request's data only
 if explicitly requested.</p>
 
 <h2 id="implementation">Implementation details</h2>
 
 <p>Several implementation details can be important to understand when developing
 an extension that uses the web request API:</p>
 
-<h3>Conflict resolution</h3>
+<h3 id="conflict_resolution">Conflict resolution</h3>
 <p>In the current implementation of the web request API, a request is considered
 as cancelled if at least one extension instructs to cancel the request. If
 an extension cancels a request, all extensions are notified by an
 <code>onErrorOccurred</code> event. Only one extension is allowed to redirect a
 request or modify a header at a time. If more than one extension attempts to
 modify the request, the most recently installed extension wins and all others
 are ignored. An extension is not notified if its instruction to modify or
 redirect has been ignored.</p>
 
-<h3>Caching</h3>
+<h3 id="caching">Caching</h3>
 <p>
 Chrome employs two caches &mdash; an on-disk cache and a very fast in-memory
 cache.  The lifetime of an in-memory cache is attached to the lifetime of a
 render process, which roughly corresponds to a tab. Requests that are answered
 from the in-memory cache are invisible to the web request API. If a request
 handler changes its behavior (for example, the behavior according to which
 requests are blocked), a simple page refresh might not respect this changed
 behavior.  To make sure the behavior change goes through, call
 <code>handlerBehaviorChanged()</code> to flush the in-memory cache. But don't do
 it often; flushing the cache is a very expensive operation. You don't need to
 call <code>handlerBehaviorChanged()</code> after registering or unregistering an
 event listener.</p>
 
-<h3>Timestamps</h3>
+<h3 id="timestamps">Timestamps</h3>
 <p>
 The <code>timestamp</code> property of web request events is only guaranteed to
 be <i>internally</i> consistent. Comparing one event to another event will give
 you the correct offset between them, but comparing them to the current time
 inside the extension (via <code>(new Date()).getTime()</code>, for instance)
 might give unexpected results.
 </p>
 
 <h2 id="examples">Examples</h2>
 
@@ skipping 32 matching lines @@
         break;
       }
     }
     return {requestHeaders: details.requestHeaders};
   },
   {urls: ["&lt;all_urls&gt;"]},
   ["blocking", "requestHeaders"]);
 </pre>
 
 <p> For more example code, see the <a href="samples.html#webrequest">web request
-samples</a>.</p>
+samples</a>.</p>