Remove .html extension from links

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

 <h1>Using eval in Chrome Extensions. Safely.</h1>
 
 
 <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>
 
 <p>
   We recognize, however, that a variety of libraries use <code>eval()</code> and
   <code>eval</code>-like constructs such as <code>new Function()</code> for
   performance optimization and ease of expression. Templating libraries are
   especially prone to this style of implementation. While some (like
   <a href='http://angularjs.org/'>Angular.js</a>) support CSP out of the box,
@@ skipping 30 matching lines @@
   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
   us back a result. This simple messaging mechanism gives us everything we need
   to safely include <code>eval</code>-driven code in our extension's workflow.
 </p>
 
 <h2 id="creating_and_using">Creating and using a sandbox.</h2>
 
 <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.
   For those of you who'd like a little more explanation, let's walk through that
   sample together here.
 </p>
 
 <h3 id="list_files">List files in manifest</h3>
 
 <p>
@@ skipping 13 matching lines @@
   ...
 }
 </pre>
 
 <h3 id="load_file">Load the sandboxed file</h3>
 
 <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
+  has been loaded into the extension's <a href='event_pages'>Event
   Page</a> (<a href='/extensions/examples/howto/sandbox/eventpage.html'>eventpage.html</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
   executing the <code>postMessage</code> method on its
   <code>contentWindow</code>. The message is an object containing two
   properties: <code>context</code> and <code>command</code>. We'll dive into
   both in a moment.
 </p>
 
@@ skipping 72 matching lines @@
       // case 'somethingElse':
       //   ...
     }
   });
 &lt;/script&gt;
 </pre>
 
 <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
   through some clever attack would be unable to inject dangerous script or
   plugin content into the high-permission extension context.
 </p>
 
 <p>
   This mechanism makes templating straightforward, but it of course isn't
   limited to templating. Any code that doesn't work out of the box under a
   strict Content Security Policy can be sandboxed; in fact, it's often useful
   to sandbox components of your extensions that <em>would</em> run correctly in
   order to restrict each piece of your program to the smallest set of privileges
   necessary for it to properly execute. The
   <a href="http://www.youtube.com/watch?v=GBxv8SaX0gg">Writing Secure Web Apps
   and Chrome Extensions</a> presentation from Google I/O 2012 gives some good
   examples of these technique in action, and is worth 56 minutes of your time.
 </p>