Remove scoped_refptr::release which is confusing and causes leaks.

chrome/browser/extensions/api/page_capture/page_capture_api.cc

Index: chrome/browser/extensions/api/page_capture/page_capture_api.cc
diff --git a/chrome/browser/extensions/api/page_capture/page_capture_api.cc b/chrome/browser/extensions/api/page_capture/page_capture_api.cc
index 8c58db6227345d67925340b40508bebe6f6c6b7b..92dc67ac340dfce9ad50bcc1a4cd4ae6608a7f4c 100644
--- a/chrome/browser/extensions/api/page_capture/page_capture_api.cc
+++ b/chrome/browser/extensions/api/page_capture/page_capture_api.cc
@@ -44,8 +44,9 @@ PageCaptureSaveAsMHTMLFunction::PageCaptureSaveAsMHTMLFunction() {
 
 PageCaptureSaveAsMHTMLFunction::~PageCaptureSaveAsMHTMLFunction() {
   if (mhtml_file_.get()) {
+    mhtml_file_->AddRef();
     BrowserThread::ReleaseSoon(BrowserThread::IO, FROM_HERE,
-                               mhtml_file_.release());
+                               mhtml_file_.get());

[michaeln, 2012/12/06 00:26:12]

This pattern is buggy.

You should also clear out the ref held in mhtml_file_ prior to invoking
ReleaseSoon. That release task may run on the target thread prior to this thread
making progress. When that happens the final release will occur on the wrong
thread.

[piman, 2012/12/06 04:56:27]

You're right, done. I verified that the other changes are not subject to this
caveat (mostly because they call release on a local variable, that isn't visible
from other threads).

Note however that the new version, no more and no less than the new version, has
any way to ensure that some other thing (e.g. a posted task) doesn't have a
separate reference to that object.

   }
 }