Update brotli to v1.0.0-snapshot.

chrome/browser/ui/webui/about_ui.cc

Index: chrome/browser/ui/webui/about_ui.cc
diff --git a/chrome/browser/ui/webui/about_ui.cc b/chrome/browser/ui/webui/about_ui.cc
index 1e8943c3be705973860f734c150886d27f0798e3..85a2d439768affa34a5eeeb4518d42683f51716c 100644
--- a/chrome/browser/ui/webui/about_ui.cc
+++ b/chrome/browser/ui/webui/about_ui.cc
@@ -8,6 +8,7 @@
 #include <stdint.h>
 
 #include <algorithm>
+#include <brotli/decode.h>

[msw, 2016/11/29 19:28:40]

Why change the include type? Is this common for third-party headers?

[eustas, 2016/11/29 23:19:22]

Brotli API headers refer each other in a "system include" way. I suppose that
clients should do the same for consistency.

[msw, 2016/11/29 23:35:59]

I'm not sure if that's true; really, I just don't know.

[Kunihiko Sakamoto, 2016/11/30 06:17:31]

It seems #include "third_party/..." style is more common in Chromium.
Including with explicit third_party/ path is easier to follow too, IMO.

chromium/src$ git grep '<zlib.h>' |grep -v '^third_party/' |wc
      2       4     141
chromium/src$ git grep '"third_party/zlib/zlib.h"' |grep -v '^third_party/' |wc
     36      72    2795

[eustas, 2016/12/02 11:49:42]

Fixed

 #include <string>
 #include <utility>
 #include <vector>
@@ -64,7 +65,6 @@
 #include "net/http/http_response_headers.h"
 #include "net/url_request/url_fetcher.h"
 #include "net/url_request/url_request_status.h"
-#include "third_party/brotli/dec/decode.h"
 #include "ui/base/l10n/l10n_util.h"
 #include "ui/base/resource/resource_bundle.h"
 #include "ui/base/webui/jstemplate_builder.h"
@@ -764,19 +764,19 @@ void AboutUIHTMLSource::StartDataRequest(
     base::StringPiece raw_response =
         ResourceBundle::GetSharedInstance().GetRawDataResource(idr);
     if (idr == IDR_ABOUT_UI_CREDITS_HTML) {
-      size_t decoded_size;
-      const uint8_t* encoded_response_buffer =
-          reinterpret_cast<const uint8_t*>(raw_response.data());
-      CHECK(BrotliDecompressedSize(raw_response.size(), encoded_response_buffer,
-                                   &decoded_size));
-
-      // Resizing the response and using it as the buffer Brotli decompresses
-      // into.
-      response.resize(decoded_size);
-      CHECK(BrotliDecompressBuffer(raw_response.size(), encoded_response_buffer,
-                                   &decoded_size,
-                                   reinterpret_cast<uint8_t*>(&response[0])) ==
-            BROTLI_RESULT_SUCCESS);
+      const uint8_t* in = reinterpret_cast<const uint8_t*>(raw_response.data());
+      size_t available_in = raw_response.size();
+      BrotliDecoderState* decoder = BrotliDecoderCreateInstance(0, 0, 0);

[msw, 2016/11/29 19:28:40]

Someone familiar with Brotli should probably review this CL before misc OWNERS.

[eustas, 2016/11/29 23:19:22]

FWIW, I develop and support Brotli last 20 months.

[msw, 2016/11/29 23:35:59]

That doesn't qualify me to review your changes in Chromium :)

[eustas, 2016/12/02 11:49:42]

It might be difficult to find the right person.
We should ask net/ developers to take a look.

+      CHECK(!!decoder);
+      while (!BrotliDecoderIsFinished(decoder)) {
+        size_t available_out = 0;
+        CHECK(BrotliDecoderDecompressStream(decoder, &available_in, &in,
+                                            &available_out, 0,
+                                            0) != BROTLI_DECODER_RESULT_ERROR);
+        const uint8_t* out = BrotliDecoderTakeOutput(decoder, &available_out);
+        response.insert(response.end(), out, out + available_out);
+      }
+      BrotliDecoderDestroyInstance(decoder);
     } else {
       response = raw_response.as_string();
     }