Inline docs render properly in extensions doc server.

chrome/common/extensions/api/downloads.idl

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 [permissions=downloads]
 namespace downloads {
   [inline_doc] dictionary HeaderNameValuePair {
     // Name of the HTTP header.
     DOMString name;
 
@@ skipping 14 matching lines @@
   // $ref:onDeterminingFilename listeners may pass a $ref:FilenameSuggestion
   // object to <code>suggest()</code> in order to override a download's target
   // filename.
   [inline_doc] dictionary FilenameSuggestion {
     // The $ref:DownloadItem's new target $ref:DownloadItem.filename, as a path
     // relative to the user's default Downloads directory, possibly containing
     // subdirectories. Absolute paths, empty paths, and paths containing
     // back-references ".." will be ignored.
     DOMString filename;
 
     // The action to take if $ref:FilenameSuggestion.filename already exists.

[benjhayden, 2013/04/17 13:28:18]

<code>filename</code>

[jshumway, 2013/04/18 01:14:19]

Got the replacement and another. I wonder why these did not cause an error
during the ref look up.

[benjhayden, 2013/04/18 15:08:46]

It might be good to figure this out before committing so that this kind of error
doesn't creep back in when people like me edit the IDLs.
Does the ref lookup run before or after _InlineDocs?
Should _InlineDocs remove the inlined type from the schema when it replaces its
uses so that ref lookup can't find it?

     FilenameConflictAction? conflict_action;
   };
 
   [inline_doc] enum HttpMethod {GET, POST};
 
   [inline_doc] dictionary DownloadOptions {
     // The URL to download.
     DOMString url;
 
     // A file path relative to the Downloads directory to contain the downloaded
@@ skipping 412 matching lines @@
     // extension may not register more than one listener for this event. Each
     // listener must call <code>suggest</code> exactly once, either
     // synchronously or asynchronously. If the listener calls
     // <code>suggest</code> asynchronously, then it must return
     // <code>true</code>. If the listener neither calls <code>suggest</code>
     // synchronously nor returns <code>true</code>, then <code>suggest</code>
     // will be called automatically. The $ref:DownloadItem will not complete
     // until all listeners have called <code>suggest</code>. Listeners may call
     // <code>suggest</code> without any arguments in order to allow the download
     // to use <code>downloadItem.filename</code> for its filename, or pass a
-    // $ref:FilenameSuggestion object to <code>suggest</code> in order to
-    // override the target filename. If more than one extension overrides the
+    // <code>FilenameSuggestion</code> object to <code>suggest</code> in order
+    // to override the target filename. If more than one extension overrides the
     // filename, then the last extension installed whose listener passes a
-    // $ref:FilenameSuggestion object to <code>suggest</code> wins. In order to
-    // avoid confusion regarding which extension will win, users should not
-    // install extensions that may conflict. If the download is initiated by
+    // <code>FilenameSuggestion</code> object to <code>suggest</code> wins. In
+    // order to avoid confusion regarding which extension will win, users should
+    // not install extensions that may conflict. If the download is initiated by
     // $ref:download and the target filename is known before the MIME type and
     // tentative filename have been determined, use
-    // $ref:DownloadOptions.filename instead.
+    // <code>DownloadOptions.filename</code> instead.
     [maxListeners=1] static void onDeterminingFilename(
         DownloadItem downloadItem, SuggestFilenameCallback suggest);
   };
 };