Remove .html extension from links

chrome/common/extensions/docs/templates/articles/sandboxingEval.html

Index: chrome/common/extensions/docs/templates/articles/sandboxingEval.html
diff --git a/chrome/common/extensions/docs/templates/articles/sandboxingEval.html b/chrome/common/extensions/docs/templates/articles/sandboxingEval.html
index d8746d1e6ab9a2efa6250941741b5666cd9a5ae3..aab051d26ce0320bca80229f10160ea37e8d0b89 100644
--- a/chrome/common/extensions/docs/templates/articles/sandboxingEval.html
+++ b/chrome/common/extensions/docs/templates/articles/sandboxingEval.html
@@ -3,13 +3,13 @@
 
 <p>
   Chrome's extension system enforces a fairly strict default
-  <a href='../extensions/contentSecurityPolicy.html'>
+  <a href='../extensions/contentSecurityPolicy'>
     <strong>Content Security Policy (CSP)</strong>
   </a>. The policy restrictions are straightforward: script must be moved
   out-of-line into separate JavaScript files, inline event handlers must be
   converted to use <code>addEventListener</code>, and <code>eval()</code> is
   disabled. Chrome Apps have an
-  <a href='contentSecurityPolicy.html'>even more strict
+  <a href='contentSecurityPolicy'>even more strict
   policy</a>, and we're quite happy with the security properties these policies
   provide.
 </p>
@@ -48,7 +48,7 @@
 <p>
   We accomplish this by listing specific HTML files inside the extension package
   as being sandboxed. Whenever a sandboxed page is loaded, it will be moved to a
-  <a href='http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-origin-browsing-context-flag'>unique origin</a>,
+  <a href='http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0#sandboxed-origin-browsing-context-flag'>unique origin</a>,
   and will be denied access to <code>chrome.*</code> APIs. If we load this
   sandboxed page into our extension via an <code>iframe</code>, we can pass it
   messages, let it act upon those messages in some way, and wait for it to pass
@@ -60,7 +60,7 @@
 
 <p>
   If you'd like to dive straight into code, please grab the
-  <a href='/extensions/samples.html#sandboxed-frame'>sandboxing
+  <a href='/extensions/samples#sandboxed-frame'>sandboxing
   sample extension and take off</a>. It's a working example of a tiny messaging
   API built on top of the <a href='http://handlebarsjs.com'>Handlebars</a>
   templating library, and it should give you everything you need to get going.
@@ -75,14 +75,14 @@
   extension manifest by adding a <code>sandbox</code> property. This is a
   critical step, and it's easy to forget, so please double check that your
   sandboxed file is listed in the manifest. In this sample, we're sandboxing the
-  file cleverly named "sandbox.html". The manifest entry looks like this:
+  file cleverly named "sandbox". The manifest entry looks like this:
 </p>
 
 <pre data-filename="manifest.json">
 {
   ...,
   "sandbox": {
-     "pages": ["sandbox.html"]
+     "pages": ["sandbox"]
   },
   ...
 }
@@ -93,9 +93,9 @@
 <p>
   In order to do something interesting with the sandboxed file, we need to load
   it in a context where it can be addressed by the extension's code. Here,
-  <a href='/extensions/examples/howto/sandbox/sandbox.html'>sandbox.html</a>
-  has been loaded into the extension's <a href='event_pages.html'>Event
-  Page</a> (<a href='/extensions/examples/howto/sandbox/eventpage.html'>eventpage.html</a>)
+  <a href='/extensions/examples/howto/sandbox/sandbox'>sandbox</a>
+  has been loaded into the extension's <a href='event_pages'>Event
+  Page</a> (<a href='/extensions/examples/howto/sandbox/eventpage'>eventpage</a>)
   via an <code>iframe</code>. <a href='/extensions/examples/howto/sandbox/eventpage.js'>eventpage.js</a>
   contains code that sends a message into the sandbox whenever the browser
   action is clicked by finding the <code>iframe</code> on the page, and
@@ -128,11 +128,11 @@ chrome.browserAction.onClicked.addListener(function() {
 <h3 id="do_something">Do something dangerous</h3>
 
 <p>
-  When <code>sandbox.html</code> is loaded, it loads the Handlebars library, and
+  When <code>sandbox</code> is loaded, it loads the Handlebars library, and
   creates and compiles an inline template in the way Handlebars suggests:
 </p>
 
-<pre data-filename="sandbox.html">
+<pre data-filename="sandbox">
 &lt;script src="handlebars-1.0.0.beta.6.js"&gt;&lt;/script&gt;
 &lt;script id="hello-world-template" type="text/x-handlebars-template"&gt;
   &lt;div class="entry"&gt;
@@ -164,7 +164,7 @@ chrome.browserAction.onClicked.addListener(function() {
   Page so the extension can do something useful with it later on:
 </p>
 
-<pre data-filename="sandbox.html">
+<pre data-filename="sandbox">
 &lt;script&gt;
   window.addEventListener('message', function(event) {
     var command = event.data.command;
@@ -187,7 +187,7 @@ chrome.browserAction.onClicked.addListener(function() {
 <p>
   Back in the Event Page, we'll receive this message, and do something
   interesting with the <code>html</code> data we've been passed. In this case,
-  we'll just echo it out via a <a href='desktop_notifications.html'>Desktop
+  we'll just echo it out via a <a href='desktop_notifications'>Desktop
   Notification</a>, but it's entirely possible to use this HTML safely as part
   of the extension's UI. Inserting it via <code>innerHTML</code> doesn't pose a
   significant security risk, as even a complete compromise of the sandboxed code