Consistent content placement method for dom-distiller

ios/chrome/browser/dom_distiller/distiller_viewer.cc

Index: ios/chrome/browser/dom_distiller/distiller_viewer.cc
diff --git a/ios/chrome/browser/dom_distiller/distiller_viewer.cc b/ios/chrome/browser/dom_distiller/distiller_viewer.cc
index bf30950290303c6a3d4115fdb5eac1a290cf37f5..9a6f745297e15040bf51c6b03a087fa1516333ac 100644
--- a/ios/chrome/browser/dom_distiller/distiller_viewer.cc
+++ b/ios/chrome/browser/dom_distiller/distiller_viewer.cc
@@ -38,8 +38,8 @@ DistillerViewer::~DistillerViewer() {
 
 void DistillerViewer::OnArticleReady(
     const DistilledArticleProto* article_proto) {
-  const std::string html = viewer::GetUnsafeArticleHtml(
-      article_proto, distilled_page_prefs_->GetTheme(),
+  const std::string html = viewer::GetUnsafeArticleTemplateHtml(
+      &article_proto->pages(0), distilled_page_prefs_->GetTheme(),

[cjhopman, 2015/03/27 00:45:15]

It looks like your change will make it so iOS doesn't get any of the data (as
they were relying on it all being in the initial html).

One approach that might give them the content is to append a <script> tag that
contains the javascript to call for all of the pages.

[cjhopman, 2015/03/27 00:48:33]

I don't see the code that uses this for iOS (maybe it's internal) so I don't
know what else might work. noyau@ probably has an idea. If they can call
javascript in the page when the callback is run, maybe the callback could take
both the html and a bit of javascript to call to insert the content.

[mdjones, 2015/03/30 23:12:27]

Done, but this should be considered a temporary fix.

[mdjones, 2015/03/30 23:12:27]

Acknowledged.

       distilled_page_prefs_->GetFontFamily());
 
   callback_.Run(url_, html);