Update brotli to v1.0.0-snapshot.

Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 222564 (02 Dec 2016)

BUG=641008
Committed: https://crrev.com/6ed4c41351b1b3f9de0613a5cb98cceb95654464
Cr-Commit-Position: refs/heads/master@{#438504}

[eustas, 2016-11-29 16:40:41]

This update brings new API, and more conservative memory allocation behaviour.

[eustas, 2016-11-29 16:41:54]

eustas@chromium.org changed reviewers:
+ kcc@chromium.org, ksakamoto@chromium.org, marq@chromium.org, msw@chromium.org,
rdsmith@chromium.org

[eustas, 2016-11-29 16:41:55]

kcc@chromium.org: Please review changes in testing/

marq@chromium.org: Please review changes in about_ui.cc

msw@chromium.org: Please review changes in about_ui.cc

rdsmith@chromium.org: Please review changes in net/

ksakamoto@chromium.org: Please review changes in brotli/

[eustas, 2016-11-29 16:45:15]

eustas@chromium.org changed reviewers:
+ bashi@chromium.org

[eustas, 2016-11-29 16:45:17]

bashi@chromium.org: Please review changes in ots/

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

I'm not used to seeing manual updating of third-party files, don't we usually
roll DEPS? Please seek informed review here before getting OWNERS stamps.

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
File chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:11: #include <brotli/decode.h>
Why change the include type? Is this common for third-party headers?

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:769: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
Someone familiar with Brotli should probably review this CL before misc OWNERS.

[eustas, 2016-11-29 23:19:07]

On 2016/11/29 19:28:40, msw wrote:
> I'm not used to seeing manual updating of third-party files, don't we usually
> roll DEPS? Please seek informed review here before getting OWNERS stamps.

Historically brotli wasn't pulled as a whole (only decoder was taken).
Later there were cheery-picks and in-place fixes.
Yes, ideally, we should pick up Brotli via DEPS machinery.
But this might be impossible (e.g. take a look at WOFF2 - there is no version
that uses new Brotli API -> it would block using newer brotli version if it was
picked up with DEPS).

[eustas, 2016-11-29 23:19:23]

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
File chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:11: #include <brotli/decode.h>
On 2016/11/29 19:28:40, msw wrote:
> Why change the include type? Is this common for third-party headers?

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

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:769: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
On 2016/11/29 19:28:40, msw wrote:
> Someone familiar with Brotli should probably review this CL before misc
OWNERS.

FWIW, I develop and support Brotli last 20 months.

[bashi, 2016-11-29 23:34:53]

ots/ rubber-stamp LGTM

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

I'm going to have to defer to another reviewer, sorry.

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
File chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:11: #include <brotli/decode.h>
On 2016/11/29 23:19:22, eustas wrote:
> On 2016/11/29 19:28:40, msw wrote:
> > Why change the include type? Is this common for third-party headers?
> 
> Brotli API headers refer each other in a "system include" way. I suppose that
> clients should do the same for consistency.

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

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:769: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
On 2016/11/29 23:19:22, eustas wrote:
> On 2016/11/29 19:28:40, msw wrote:
> > Someone familiar with Brotli should probably review this CL before misc
> OWNERS.
> 
> FWIW, I develop and support Brotli last 20 months.

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

[Kunihiko Sakamoto, 2016-11-30 05:49:46]

The CQ bit was checked by ksakamoto@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 05:50:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 05:58:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 05:58:45]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

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

I've checked CQ dry run, and seeing compilation errors. 

It's a good idea to make sure your CL passes CQ dry run, before sending for
review.

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
File chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:11: #include <brotli/decode.h>
On 2016/11/29 23:35:59, msw wrote:
> On 2016/11/29 23:19:22, eustas wrote:
> > On 2016/11/29 19:28:40, msw wrote:
> > > Why change the include type? Is this common for third-party headers?
> > 
> > Brotli API headers refer each other in a "system include" way. I suppose
that
> > clients should do the same for consistency.
> 
> I'm not sure if that's true; really, I just don't know.

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-11-30 08:39:53]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 08:40:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eustas, 2016-11-30 08:42:52]

On 2016/11/30 06:17:31, Kunihiko Sakamoto wrote:
> It's a good idea to make sure your CL passes CQ dry run, before sending for
> review.

"CQ dry-run" says that it is only accessible for project comitters.
Unfortunately, I am not.

Compilation problem was caused by file not being uploaded (because of size
limit?). Sorry.

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

Going to fix it soon.

[commit-bot: I haz the power, 2016-11-30 08:51:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 08:51:14]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[marq (ping after 24h), 2016-11-30 09:17:42]

I have some C++ style comments for the ios/ files I am an OWNER of, but please
apply similar corrections to any other Chromium changes in this CL.

I would also, like other reviewers, prefer to have this CL reviewed by a
Chromium committer who's familiar with Bortli and how we manage third-party
includes. After those issues (and the C++ style issues) are resolved, I'll
review again for OWNER approval.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
File ios/chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:8: #include <brotli/decode.h>
I have the same concerns about changing the include type as msw@.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:134: const uint8_t* in =
reinterpret_cast<const uint8_t*>(raw_response.data());
|in| isn't a suitable variable name, since it doesn't describe what the variable
represents. Please keep the old name, |encoded_response_buffer|, unless the
semantics of the API have significantly changed.

Please review the style guide for naming rules
(https://google.github.io/styleguide/cppguide.html#General_Naming_Rules); the
overriding principle is that names must be descriptive.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:135: size_t available_in =
raw_response.size();
Likewise, |available_in| isn't a good name here. |raw_size| looks like it might
be better, or maybe |input_bytes_remaining|?

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:136: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
Please insert inline comments to document the 0 parameters. The maintainers of
this code are very likely to know nothing about Brotli.

Do not use 0 for null pointers; use nullptr. See the C++ style guide:
https://google.github.io/styleguide/cppguide.html#0_and_nullptr/NULL

So this should look something like:

BrotliDecoderCreateInstance(nullptr /* no custom allocator */, 
                            nullptr /* no custom deallocator */,
                            nullptr /* no custom memory handle */);

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:136: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
I find 'BrotliDecoderState' a very counterintuitive type name. For how it is
used, this seems to be a pointer to a decoder instance, but the type name sounds
like it's a scalar value of some kind that indicates the state of a decoder
instance.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:139: size_t available_out = 0;
Is |available_out| really something like |output_bytes_remaining|?

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:141: &available_out, 0,
Don't use 0 for null pointers here, either.

[eustas, 2016-11-30 13:38:40]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 13:38:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 14:02:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 14:02:38]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[eustas, 2016-11-30 14:58:36]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 14:59:01]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eustas, 2016-11-30 15:18:50]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 15:19:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eustas, 2016-11-30 15:26:44]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 15:27:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Randy Smith (Not in Mondays), 2016-11-30 15:27:39]

net/ LGTM.

[eustas, 2016-11-30 15:30:20]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 15:30:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 16:04:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 16:05:00]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[eustas, 2016-11-30 16:20:38]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 16:21:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 17:02:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 17:02:53]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[eustas, 2016-12-02 10:00:33]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-02 10:00:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[eustas, 2016-12-02 10:01:29]

Description was changed from

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 5db62d (09 Nov 2016)

BUG=641008
==========

to

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 6a4bf4 (02 Dec 2016)

BUG=641008
==========

[eustas, 2016-12-02 10:43:39]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-02 10:44:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-02 11:49:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-02 11:49:09]

Dry run: This issue passed the CQ dry run.

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

CQ-dry-run is green now. Thanks for the patience. PTAL.

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
File chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:11: #include <brotli/decode.h>
On 2016/11/30 06:17:31, Kunihiko Sakamoto wrote:
> On 2016/11/29 23:35:59, msw wrote:
> > On 2016/11/29 23:19:22, eustas wrote:
> > > On 2016/11/29 19:28:40, msw wrote:
> > > > Why change the include type? Is this common for third-party headers?
> > > 
> > > Brotli API headers refer each other in a "system include" way. I suppose
> that
> > > clients should do the same for consistency.
> > 
> > I'm not sure if that's true; really, I just don't know.
> 
> 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

Fixed

https://codereview.chromium.org/2537133002/diff/1/chrome/browser/ui/webui/abo...
chrome/browser/ui/webui/about_ui.cc:769: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
On 2016/11/29 23:35:59, msw wrote:
> On 2016/11/29 23:19:22, eustas wrote:
> > On 2016/11/29 19:28:40, msw wrote:
> > > Someone familiar with Brotli should probably review this CL before misc
> > OWNERS.
> > 
> > FWIW, I develop and support Brotli last 20 months.
> 
> That doesn't qualify me to review your changes in Chromium :)

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

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
File ios/chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:8: #include <brotli/decode.h>
On 2016/11/30 09:17:41, marq wrote:
> I have the same concerns about changing the include type as msw@. 

Done.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:134: const uint8_t* in =
reinterpret_cast<const uint8_t*>(raw_response.data());
On 2016/11/30 09:17:41, marq wrote:
> |in| isn't a suitable variable name, since it doesn't describe what the
variable
> represents. Please keep the old name, |encoded_response_buffer|, unless the
> semantics of the API have significantly changed.
> 
> Please review the style guide for naming rules
> (https://google.github.io/styleguide/cppguide.html#General_Naming_Rules); the
> overriding principle is that names must be descriptive.

Semantics has changed - now decompression is streaming, so this pointer changes
in a loop, until it reaches the en of input.

Done.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:135: size_t available_in =
raw_response.size();
On 2016/11/30 09:17:41, marq wrote:
> Likewise, |available_in| isn't a good name here. |raw_size| looks like it
might
> be better, or maybe |input_bytes_remaining|?

Done.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:136: BrotliDecoderState* decoder =
BrotliDecoderCreateInstance(0, 0, 0);
On 2016/11/30 09:17:41, marq wrote:
> I find 'BrotliDecoderState' a very counterintuitive type name. For how it is
> used, this seems to be a pointer to a decoder instance, but the type name
sounds
> like it's a scalar value of some kind that indicates the state of a decoder
> instance.

Good point. I'll consider renaming this structure in next brotli version.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:139: size_t available_out = 0;
On 2016/11/30 09:17:41, marq wrote:
> Is |available_out| really something like |output_bytes_remaining|?

Yup. Fixed.

https://codereview.chromium.org/2537133002/diff/1/ios/chrome/browser/ui/webui...
ios/chrome/browser/ui/webui/about_ui.cc:141: &available_out, 0,
On 2016/11/30 09:17:41, marq wrote:
> Don't use 0 for null pointers here, either.

Done.

[eustas, 2016-12-02 12:40:49]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-02 12:41:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-02 14:38:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-02 14:38:45]

Dry run: This issue passed the CQ dry run.

[Kunihiko Sakamoto, 2016-12-05 02:27:00]

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
File third_party/brotli/BUILD.gn (right):

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
third_party/brotli/BUILD.gn:20: public_configs = [ ":includes" ]
Since you're using #include "third_party/brotli/..." style now, probably you
don't need to make this public_configs.

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
third_party/brotli/BUILD.gn:37: public_configs = [ ":includes" ]
Same here

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
third_party/brotli/BUILD.gn:109: public_configs = [ ":includes" ]
Same here

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/READ...
File third_party/brotli/README.chromium (right):

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/READ...
third_party/brotli/README.chromium:3: Version:
222564a95d9ab58865a096b8d9f7324ea5f2e03e
Your CL description says 6a4bf4. Which is correct?

https://codereview.chromium.org/2537133002/diff/90001/third_party/woff2/READM...
File third_party/woff2/README.chromium (right):

https://codereview.chromium.org/2537133002/diff/90001/third_party/woff2/READM...
third_party/woff2/README.chromium:16: - src/woff2_dec.cc modified to use new
Brotli API at lines 739-741
After landing this CL, would you upstream this change?

[eustas, 2016-12-05 14:11:40]

Description was changed from

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 6a4bf4 (02 Dec 2016)

BUG=641008
==========

to

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 222564 (02 Dec 2016)

BUG=641008
==========

[eustas, 2016-12-05 14:15:01]

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
File third_party/brotli/BUILD.gn (right):

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
third_party/brotli/BUILD.gn:20: public_configs = [ ":includes" ]
On 2016/12/05 02:27:00, Kunihiko Sakamoto wrote:
> Since you're using #include "third_party/brotli/..." style now, probably you
> don't need to make this public_configs.

decode.h and encode.h include <brotli/port.h> and <brotli/types.h>.
So, if it can't removed if sources are not modified.

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
third_party/brotli/BUILD.gn:37: public_configs = [ ":includes" ]
On 2016/12/05 02:27:00, Kunihiko Sakamoto wrote:
> Same here

Acknowledged.

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/BUIL...
third_party/brotli/BUILD.gn:109: public_configs = [ ":includes" ]
On 2016/12/05 02:27:00, Kunihiko Sakamoto wrote:
> Same here

Acknowledged.

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/READ...
File third_party/brotli/README.chromium (right):

https://codereview.chromium.org/2537133002/diff/90001/third_party/brotli/READ...
third_party/brotli/README.chromium:3: Version:
222564a95d9ab58865a096b8d9f7324ea5f2e03e
On 2016/12/05 02:27:00, Kunihiko Sakamoto wrote:
> Your CL description says 6a4bf4. Which is correct?

222xxx is correct. Unfortunately revision description is not updated on
reupload. Going to fix it. Thanks!

https://codereview.chromium.org/2537133002/diff/90001/third_party/woff2/READM...
File third_party/woff2/README.chromium (right):

https://codereview.chromium.org/2537133002/diff/90001/third_party/woff2/READM...
third_party/woff2/README.chromium:16: - src/woff2_dec.cc modified to use new
Brotli API at lines 739-741
On 2016/12/05 02:27:00, Kunihiko Sakamoto wrote:
> After landing this CL, would you upstream this change?

Surely. Going to update both internal WOFF2 repo and then github. It was a some
kind of chicken-and-egg problem: it is impossible to get the same version of API
everywhere instantly...

[Kunihiko Sakamoto, 2016-12-06 01:55:50]

brotli/ and woff2/ lgtm

[marq (ping after 24h), 2016-12-07 10:09:44]

ios/ LGTM

[marq (ping after 24h), 2016-12-07 10:11:40]

https://codereview.chromium.org/2537133002/diff/90001/ios/chrome/browser/ui/w...
File ios/chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/90001/ios/chrome/browser/ui/w...
ios/chrome/browser/ui/webui/about_ui.cc:148: const uint8_t* out =
Can you please use a slightly more descriptive name than 'out'? 'output_buffer'?

[eustas, 2016-12-07 12:34:28]

https://codereview.chromium.org/2537133002/diff/90001/ios/chrome/browser/ui/w...
File ios/chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/90001/ios/chrome/browser/ui/w...
ios/chrome/browser/ui/webui/about_ui.cc:148: const uint8_t* out =
On 2016/12/07 10:11:40, marq wrote:
> Can you please use a slightly more descriptive name than 'out'?
'output_buffer'?

Of course. Done.

[eustas, 2016-12-07 12:34:55]

The CQ bit was checked by eustas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-07 12:35:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-07 13:44:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-07 13:44:44]

Dry run: This issue passed the CQ dry run.

[eustas, 2016-12-12 09:31:19]

kcc@, please take a look at testing/libfuzzer/brotli_fuzzer.cc
(now it is the same as used in external clusterfuzz)

[eustas, 2016-12-12 09:34:10]

msw@, PTAL; changes in about_ui.cc are exactly the same in ios/ and ./

[msw, 2016-12-12 19:29:08]

c/b/ui rubber stamp lgtm with a nit

https://codereview.chromium.org/2537133002/diff/100001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/about_ui.cc (right):

https://codereview.chromium.org/2537133002/diff/100001/chrome/browser/ui/webu...
chrome/browser/ui/webui/about_ui.cc:776: size_t output_size_remianing = 0;
nit: 'remaining' spelling (please check/fix elsewhere too)

[kcc2, 2016-12-12 19:33:02]

On 2016/12/12 09:31:19, eustas wrote:
> kcc@, please take a look at testing/libfuzzer/brotli_fuzzer.cc
> (now it is the same as used in external clusterfuzz)

LGTM
(for brotli_fuzzer.cc)

[eustas, 2016-12-14 12:47:58]

On 2016/12/12 19:29:08, msw wrote:
> c/b/ui rubber stamp lgtm with a nit
> 
>
https://codereview.chromium.org/2537133002/diff/100001/chrome/browser/ui/webu...
> File chrome/browser/ui/webui/about_ui.cc (right):
> 
>
https://codereview.chromium.org/2537133002/diff/100001/chrome/browser/ui/webu...
> chrome/browser/ui/webui/about_ui.cc:776: size_t output_size_remianing = 0;
> nit: 'remaining' spelling (please check/fix elsewhere too)

Ooops. Fixed. Thanks.

[eustas, 2016-12-14 12:48:26]

The CQ bit was checked by eustas@chromium.org

[eustas, 2016-12-14 12:48:27]

The patchset sent to the CQ was uploaded after l-g-t-m from bashi@chromium.org,
rdsmith@chromium.org, ksakamoto@chromium.org, marq@chromium.org,
msw@chromium.org, kcc@chromium.org
Link to the patchset: https://codereview.chromium.org/2537133002/#ps110001
(title: "Fixed typo")

[commit-bot: I haz the power, 2016-12-14 12:48:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 13:53:40]

CQ is committing da patch.

Bot data: {"patchset_id": 110001, "attempt_start_ts": 1481719706433480,
"parent_rev": "beaaf29500fd2968200a6878d777ef05eb6dc824", "commit_rev":
"8687ca2c37d11190290a9d487f78461053c20e91"}

[commit-bot: I haz the power, 2016-12-14 13:54:10]

Description was changed from

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 222564 (02 Dec 2016)

BUG=641008
==========

to

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 222564 (02 Dec 2016)

BUG=641008

Review-Url: https://codereview.chromium.org/2537133002
==========

[commit-bot: I haz the power, 2016-12-14 13:54:13]

Committed patchset #12 (id:110001)

[commit-bot: I haz the power, 2016-12-14 13:56:25]

Description was changed from

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 222564 (02 Dec 2016)

BUG=641008

Review-Url: https://codereview.chromium.org/2537133002
==========

to

==========
Update brotli to v1.0.0-snapshot.

4836af (20 May 2016) to 222564 (02 Dec 2016)

BUG=641008

Committed: https://crrev.com/6ed4c41351b1b3f9de0613a5cb98cceb95654464
Cr-Commit-Position: refs/heads/master@{#438504}
==========

[commit-bot: I haz the power, 2016-12-14 13:56:27]

Patchset 12 (id:??) landed as
https://crrev.com/6ed4c41351b1b3f9de0613a5cb98cceb95654464
Cr-Commit-Position: refs/heads/master@{#438504}