If MHTML saving is cancelled, delete the page afterwards.

chrome/browser/android/offline_pages/background_loader_offliner.cc

Index: chrome/browser/android/offline_pages/background_loader_offliner.cc
diff --git a/chrome/browser/android/offline_pages/background_loader_offliner.cc b/chrome/browser/android/offline_pages/background_loader_offliner.cc
index 6c4a9b3062be368710d69e0f30013a9f1ee276ff..c1317c06790ce1ec53a35c3593588a0cefabb8c9 100644
--- a/chrome/browser/android/offline_pages/background_loader_offliner.cc
+++ b/chrome/browser/android/offline_pages/background_loader_offliner.cc
@@ -81,6 +81,8 @@ void HandleApplicationStateChangeCancel(
   completion_callback.Run(canceled_request,
                           Offliner::RequestStatus::FOREGROUND_CANCELED);
 }
+
+void LocalDeletePageCallback(DeletePageResult result) {}
 }  // namespace
 
 BackgroundLoaderOffliner::BackgroundLoaderOffliner(
@@ -414,6 +416,11 @@ void BackgroundLoaderOffliner::OnPageSaved(SavePageResult save_result,
   ResetState();
 
   if (save_state_ == DELETE_AFTER_SAVE) {
+    // Delete the saved page off disk and from the OPM.
+    std::vector<int64_t> offline_ids;
+    offline_ids.push_back(offline_id);
+    offline_page_model_->DeletePagesByOfflineId(
+        offline_ids, base::Bind(&LocalDeletePageCallback));

[chili, 2017/04/29 00:11:33]

should we only run the cancel_callback_.Run once the delete completes?

Do we have to worry about a situation where the subsequent pending_request
starts to save before delete completes?

[Pete Williamson, 2017/04/29 00:14:44]

My thinking here is that it is fine to return control.  We only need to clean up
the page.  If we get another request for the same page, it will have a different
request ID, so the page being cleaned up should not interefere with the
operation.  If another request starts to save while deleting the page, they
should also be independent.

     save_state_ = NONE;
     cancel_callback_.Run(request);
     return;