Expose scroll customization for touch to JS (behind REF).

Expose scroll customization for touch to JS (behind REF).

This enables scroll customization of touch scrolls for JS.  See
http://goo.gl/xCBm7L for details. This is a followup to
https://codereview.chromium.org/988823003, and completes landing
https://codereview.chromium.org/850443002/.

This approach replaces the previous approach, from
https://codereview.chromium.org/1057603002.

BUG=410974
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=199049

[tdresser, 2015-07-06 16:43:16]

Patchset #2 (id:20001) has been deleted

[tdresser, 2015-07-06 16:46:12]

Patchset #2 (id:40001) has been deleted

[tdresser, 2015-07-06 20:43:00]

tdresser@chromium.org changed reviewers:
+ rbyers@chromium.org

[tdresser, 2015-07-06 20:43:01]

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
File Source/core/dom/ElementRareData.h (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
Source/core/dom/ElementRareData.h:165:
PersistentWillBeMember<ScrollStateCallback> m_distributeScroll;
We need to find somewhere else to stash these, as adding 2*sizeof(Persistent) to
every ElementRareData is an unacceptable size increase (according to haraken@).

[haraken, 2015-07-07 02:11:05]

On 2015/07/06 20:43:01, tdresser wrote:
>
https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
> File Source/core/dom/ElementRareData.h (right):
> 
>
https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
> Source/core/dom/ElementRareData.h:165:
> PersistentWillBeMember<ScrollStateCallback> m_distributeScroll;
> We need to find somewhere else to stash these, as adding 2*sizeof(Persistent)
to
> every ElementRareData is an unacceptable size increase (according to
haraken@).

In terms of V8 bindings, this CL looks good.

- Regarding sizeof(ElementRareData), I'll defer the decision to
blink-reviews-dom@.
- Regarding the scroll state implementation, I'll defer the decision to Rick.

[Rick Byers, 2015-07-07 21:24:40]

This seems like a reasonable next step - thanks!

I agree we don't want to add 2*sizeof(Persistent)*elementCount RAM usage.

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
File Source/core/dom/Element.idl (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
Source/core/dom/Element.idl:21: // http://dev.w3.org/houdini/css-scroll-api/
Since there's nothing here yet, you should instead reference your bug or your
own API doc (something that describes the semantics of the API).

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
File Source/core/dom/ElementRareData.h (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
Source/core/dom/ElementRareData.h:165:
PersistentWillBeMember<ScrollStateCallback> m_distributeScroll;
On 2015/07/06 20:43:01, tdresser wrote:
> We need to find somewhere else to stash these, as adding 2*sizeof(Persistent)
to
> every ElementRareData is an unacceptable size increase (according to
haraken@).

Can we instead have a map somewhere (per Document?) from Element to
ScrollStateCallback?  Maybe something kind of like EventHandlerRegistry?

https://codereview.chromium.org/1209183004/diff/100001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollStateCallback.idl (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.idl:5: //
http://dev.w3.org/houdini/css-scroll-api/
ditto

[tdresser, 2015-07-13 17:36:52]

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
File Source/core/dom/Element.idl (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
Source/core/dom/Element.idl:21: // http://dev.w3.org/houdini/css-scroll-api/
On 2015/07/07 21:24:40, Rick Byers wrote:
> Since there's nothing here yet, you should instead reference your bug or your
> own API doc (something that describes the semantics of the API).

Done.

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
File Source/core/dom/ElementRareData.h (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
Source/core/dom/ElementRareData.h:165:
PersistentWillBeMember<ScrollStateCallback> m_distributeScroll;
On 2015/07/07 21:24:40, Rick Byers (Out until 7-23) wrote:
> On 2015/07/06 20:43:01, tdresser wrote:
> > We need to find somewhere else to stash these, as adding
2*sizeof(Persistent)
> to
> > every ElementRareData is an unacceptable size increase (according to
> haraken@).
> 
> Can we instead have a map somewhere (per Document?) from Element to
> ScrollStateCallback?  Maybe something kind of like EventHandlerRegistry?

Per Document / Framehost would introduce a fair bit of unnecessary complexity,
as Elements can be moved between Documents and FrameHosts. We'd need to pass the
callbacks back and forth when elements are moved around. A static map isn't
particularly elegant, but it lets us tie the lifetime to the lifetime of the
Element without inflating ElementRareData, and doesn't introduce much additional
complexity.

Does this seem reasonable?

https://codereview.chromium.org/1209183004/diff/100001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollStateCallback.idl (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.idl:5: //
http://dev.w3.org/houdini/css-scroll-api/
On 2015/07/07 21:24:40, Rick Byers wrote:
> ditto

Done.

[haraken, 2015-07-13 23:43:07]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2015-07-13 23:43:08]

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
File Source/core/dom/ElementRareData.h (right):

https://codereview.chromium.org/1209183004/diff/100001/Source/core/dom/Elemen...
Source/core/dom/ElementRareData.h:165:
PersistentWillBeMember<ScrollStateCallback> m_distributeScroll;
On 2015/07/13 17:36:52, tdresser wrote:
> On 2015/07/07 21:24:40, Rick Byers (Out until 7-23) wrote:
> > On 2015/07/06 20:43:01, tdresser wrote:
> > > We need to find somewhere else to stash these, as adding
> 2*sizeof(Persistent)
> > to
> > > every ElementRareData is an unacceptable size increase (according to
> > haraken@).
> > 
> > Can we instead have a map somewhere (per Document?) from Element to
> > ScrollStateCallback?  Maybe something kind of like EventHandlerRegistry?
> 
> Per Document / Framehost would introduce a fair bit of unnecessary complexity,
> as Elements can be moved between Documents and FrameHosts. We'd need to pass
the
> callbacks back and forth when elements are moved around. A static map isn't
> particularly elegant, but it lets us tie the lifetime to the lifetime of the
> Element without inflating ElementRareData, and doesn't introduce much
additional
> complexity.
> 
> Does this seem reasonable?

A static map is fine. See how CustomElementObserverMap works. We can do a
similar thing here.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

[tdresser, 2015-07-14 14:00:08]

I've cleaned up the static map.

[tdresser, 2015-07-14 19:39:51]

tdresser@chromium.org changed reviewers:
+ skobes@chromium.org
- rbyers@chromium.org

[tdresser, 2015-07-14 19:39:52]

Rick is out for a week and a half - skobes he recommended you as a good reviewer
for this change.

Can you take a look?

For some additional context on why the bindings look the way they do, you could
skim the conversation here: https://codereview.chromium.org/1057603002. TL;DR,
these bindings are temporary, and making them any prettier would be more trouble
than it's worth.

[haraken, 2015-07-15 00:15:18]

bindings/ and dom/ LGTM

https://codereview.chromium.org/1209183004/diff/140001/Source/core/dom/Elemen...
File Source/core/dom/Element.cpp (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/dom/Elemen...
Source/core/dom/Element.cpp:143: {

Can we add ASSERT(RuntimeEnabledFeature::ScrollCustomization) ?

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollState.idl (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollState.idl:5: // https://goo.gl/1ipTpP

Can we use a full URL?

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollStateCallback.h (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.h:14: enum class
NativeScrollBehavior;

Remove this. Or I think we can move the contents of NativeScrollBehavior.h here
(and remove NativeScrollBehavior.h).

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.h:18: ScrollStateCallback()

Add explicit.

[tdresser, 2015-07-15 14:04:55]

https://codereview.chromium.org/1209183004/diff/140001/Source/core/dom/Elemen...
File Source/core/dom/Element.cpp (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/dom/Elemen...
Source/core/dom/Element.cpp:143: {
On 2015/07/15 00:15:18, haraken wrote:
> 
> Can we add ASSERT(RuntimeEnabledFeature::ScrollCustomization) ?

Done.

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollState.idl (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollState.idl:5: // https://goo.gl/1ipTpP
On 2015/07/15 00:15:18, haraken wrote:
> 
> Can we use a full URL?

Done.

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollStateCallback.h (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.h:14: enum class
NativeScrollBehavior;
On 2015/07/15 00:15:18, haraken wrote:
> 
> Remove this. Or I think we can move the contents of NativeScrollBehavior.h
here
> (and remove NativeScrollBehavior.h).

Removed NativeScrollBehavior.h.

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.h:18: ScrollStateCallback()
On 2015/07/15 00:15:18, haraken wrote:
> 
> Add explicit.

When there are 0 parameters?
Done, but `git grep "explicit [A-Za-z]*()" -- "*.h" only has 4 results. It
doesn't look like this is a common pattern, and I didn't think the explicit
keyword did anything when there are 0 parameters.

[haraken, 2015-07-15 14:07:17]

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollStateCallback.h (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollStateCallback.h:18: ScrollStateCallback()
On 2015/07/15 14:04:55, tdresser wrote:
> On 2015/07/15 00:15:18, haraken wrote:
> > 
> > Add explicit.
> 
> When there are 0 parameters?
> Done, but `git grep "explicit [A-Za-z]*()" -- "*.h" only has 4 results. It
> doesn't look like this is a common pattern, and I didn't think the explicit
> keyword did anything when there are 0 parameters.

Sorry, you're right.

[skobes, 2015-07-15 19:52:41]

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollState.idl (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollState.idl:5: // https://goo.gl/1ipTpP
On 2015/07/15 00:15:18, haraken wrote:
> 
> Can we use a full URL?

@haraken: Just curious, why do you want the full URL?  (I prefer the short URL
for readability, but I don't feel strongly about it.)

https://codereview.chromium.org/1209183004/diff/180001/LayoutTests/fast/scrol...
File
LayoutTests/fast/scroll-behavior/scroll-customization/scrollstate-basic.html
(right):

https://codereview.chromium.org/1209183004/diff/180001/LayoutTests/fast/scrol...
LayoutTests/fast/scroll-behavior/scroll-customization/scrollstate-basic.html:14:
}, "These tests only work with scroll customization enabled.");
Why doesn't the test enable scroll customization through internals.settings?

https://codereview.chromium.org/1209183004/diff/180001/Source/core/core.gypi
File Source/core/core.gypi (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/core.gypi#...
Source/core/core.gypi:246: 'page/scrolling/ScrollStateCallback.idl',
fix indentation

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
File Source/core/dom/Element.cpp (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
Source/core/dom/Element.cpp:562: // Handle the scrollingElement separately, as
it scrolls the FrameView.
Can you change "FrameView" -> "viewport" here?

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
File Source/core/dom/Element.idl (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
Source/core/dom/Element.idl:112: [RuntimeEnabled=ScrollCustomization] void
setApplyScroll(ScrollStateCallback scrollStateCallback, NativeScrollBehavior
nativeScrollBehavior);
You mentioned the bindings are temporary... does that mean the eventual plan is
to allow direct assignment to element.applyScroll?  IMHO that's more intuitive
than setApplyScroll, and we shouldn't compromise the API for ease of
implementation.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollCustomizationCallbacks.cpp (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollCustomizationCallbacks.cpp:15: }
Put blank lines between functions.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollCustomizationCallbacks.h (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollCustomizationCallbacks.h:38: using
ScrollStateCallbackList = HeapHashMap<RawPtrWillBeWeakMember<Element>,
Member<ScrollStateCallback>>;
Is there a reason this is HeapHashMap and not just HashMap?

[haraken, 2015-07-15 23:33:19]

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollState.idl (right):

https://codereview.chromium.org/1209183004/diff/140001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollState.idl:5: // https://goo.gl/1ipTpP
On 2015/07/15 19:52:40, skobes wrote:
> On 2015/07/15 00:15:18, haraken wrote:
> > 
> > Can we use a full URL?
> 
> @haraken: Just curious, why do you want the full URL?  (I prefer the short URL
> for readability, but I don't feel strongly about it.)

That's just a convention. We've been adding a full URL in Blink IDL files (which
is helpful to see if the spec is a whatwg one or a w3c one etc).

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollCustomizationCallbacks.h (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollCustomizationCallbacks.h:38: using
ScrollStateCallbackList = HeapHashMap<RawPtrWillBeWeakMember<Element>,
Member<ScrollStateCallback>>;
On 2015/07/15 19:52:40, skobes wrote:
> Is there a reason this is HeapHashMap and not just HashMap?

This must be a HeapHashMap because this is the objects in the map need to be
traced.

[tdresser, 2015-07-16 17:11:14]

https://codereview.chromium.org/1209183004/diff/180001/LayoutTests/fast/scrol...
File
LayoutTests/fast/scroll-behavior/scroll-customization/scrollstate-basic.html
(right):

https://codereview.chromium.org/1209183004/diff/180001/LayoutTests/fast/scrol...
LayoutTests/fast/scroll-behavior/scroll-customization/scrollstate-basic.html:14:
}, "These tests only work with scroll customization enabled.");
On 2015/07/15 19:52:40, skobes wrote:
> Why doesn't the test enable scroll customization through internals.settings?

Is that possible? It looks like internals.settings doesn't let you set runtime
enabled features.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

Also, Rick was in favor of having some scroll customization tests that failed
because scroll customization isn't enabled by default yet.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/core.gypi
File Source/core/core.gypi (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/core.gypi#...
Source/core/core.gypi:246: 'page/scrolling/ScrollStateCallback.idl',
On 2015/07/15 19:52:40, skobes wrote:
> fix indentation

Done.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
File Source/core/dom/Element.cpp (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
Source/core/dom/Element.cpp:562: // Handle the scrollingElement separately, as
it scrolls the FrameView.
On 2015/07/15 19:52:40, skobes wrote:
> Can you change "FrameView" -> "viewport" here?

Done.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
File Source/core/dom/Element.idl (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
Source/core/dom/Element.idl:112: [RuntimeEnabled=ScrollCustomization] void
setApplyScroll(ScrollStateCallback scrollStateCallback, NativeScrollBehavior
nativeScrollBehavior);
On 2015/07/15 19:52:40, skobes wrote:
> You mentioned the bindings are temporary... does that mean the eventual plan
is
> to allow direct assignment to element.applyScroll?  IMHO that's more intuitive
> than setApplyScroll, and we shouldn't compromise the API for ease of
> implementation.

The final API is still somewhat up in the air, hence the temporary bindings. The
plan is to align this API with the rest of the houdini effort (custom layout and
custom paint).

In particular, see http://dev.w3.org/houdini/css-paint-api/#issue-5a80a930. We
may end up with a registerCustomScroller method similar to registerCustomPaint,
and we may pass in a class with applyScroll and distributeScroll methods. 

One option is to have a class available, perhaps CustomScroller. You'd inherit
from CustomScroller, and be able to call super to access the default scrolling
implementation.

There's still some work to be done to finalize the custom layout and custom
paint API's though, so for now we're just going to land this temporary API so
folks can get a feel for using scroll customization.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
File Source/core/page/scrolling/ScrollCustomizationCallbacks.cpp (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/page/scrol...
Source/core/page/scrolling/ScrollCustomizationCallbacks.cpp:15: }
On 2015/07/15 19:52:40, skobes wrote:
> Put blank lines between functions.

Done.

[skobes, 2015-07-16 18:56:41]

lgtm

https://codereview.chromium.org/1209183004/diff/180001/LayoutTests/fast/scrol...
File
LayoutTests/fast/scroll-behavior/scroll-customization/scrollstate-basic.html
(right):

https://codereview.chromium.org/1209183004/diff/180001/LayoutTests/fast/scrol...
LayoutTests/fast/scroll-behavior/scroll-customization/scrollstate-basic.html:14:
}, "These tests only work with scroll customization enabled.");
On 2015/07/16 17:11:14, tdresser wrote:
> On 2015/07/15 19:52:40, skobes wrote:
> > Why doesn't the test enable scroll customization through internals.settings?
> 
> Is that possible? It looks like internals.settings doesn't let you set runtime
> enabled features.

Hmm, I had assumed it did but looks like only a few are exposed and there is a
FIXME to remove them.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

> Also, Rick was in favor of having some scroll customization tests that failed
> because scroll customization isn't enabled by default yet.

Ack.

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
File Source/core/dom/Element.idl (right):

https://codereview.chromium.org/1209183004/diff/180001/Source/core/dom/Elemen...
Source/core/dom/Element.idl:112: [RuntimeEnabled=ScrollCustomization] void
setApplyScroll(ScrollStateCallback scrollStateCallback, NativeScrollBehavior
nativeScrollBehavior);
On 2015/07/16 17:11:14, tdresser wrote:
> On 2015/07/15 19:52:40, skobes wrote:
> > You mentioned the bindings are temporary... does that mean the eventual plan
> is
> > to allow direct assignment to element.applyScroll?  IMHO that's more
intuitive
> > than setApplyScroll, and we shouldn't compromise the API for ease of
> > implementation.
> 
> The final API is still somewhat up in the air, hence the temporary bindings.
The
> plan is to align this API with the rest of the houdini effort (custom layout
and
> custom paint).
> 
> In particular, see http://dev.w3.org/houdini/css-paint-api/#issue-5a80a930. We
> may end up with a registerCustomScroller method similar to
registerCustomPaint,
> and we may pass in a class with applyScroll and distributeScroll methods. 
> 
> One option is to have a class available, perhaps CustomScroller. You'd inherit
> from CustomScroller, and be able to call super to access the default scrolling
> implementation.
> 
> There's still some work to be done to finalize the custom layout and custom
> paint API's though, so for now we're just going to land this temporary API so
> folks can get a feel for using scroll customization.

Sounds good, thanks for adding context here.

[tdresser, 2015-07-16 19:01:17]

The CQ bit was checked by tdresser@chromium.org

[tdresser, 2015-07-16 19:01:18]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/1209183004/#ps200001
(title: "Address skobes' nits.")

[commit-bot: I haz the power, 2015-07-16 19:01:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1209183004/200001

[commit-bot: I haz the power, 2015-07-16 19:06:44]

Committed patchset #9 (id:200001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=199049

[Julien - ping for review, 2015-07-17 00:19:54]

A revert of this CL (patchset #9 id:200001) has been created in
https://codereview.chromium.org/1239993005/ by jchaffraix@chromium.org.

The reason for reverting is: The change introduced some leaks on our bots for:
virtual/scroll_customization/fast/scroll-behavior/scroll-customization/scrollstate-distribute-to-scroll-chain-descendant.html
virtual/scroll_customization/fast/scroll-behavior/scroll-customization/touch-scroll-customization.html

Output is:
({"numberOfLiveActiveDOMObjects":[2,4],"numberOfLiveDocuments":[1,2],"numberOfLiveNodes":[4,36],"numberOfLiveResources":[0,2]})

Full output:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Leak/b....

[loyso (OOO), 2015-07-17 03:52:40]

This CL also causes TEXT size regression on Builder: Mac (stats)

RESULT Chromium: Chromium= 8584 bytes
RESULT Chromium-__TEXT: __TEXT= 4096 bytes
RESULT Chromium-__DATA: __DATA= 4096 bytes
RESULT Chromium-__OBJC: __OBJC= 0 bytes
RESULT ChromiumFramework: ChromiumFramework= 106535924 bytes
RESULT ChromiumFramework-__TEXT: __TEXT= 100904960 bytes
RESULT ChromiumFramework-__DATA: __DATA= 5595136 bytes
RESULT ChromiumFramework-__OBJC: __OBJC= 0 bytes
RESULT Chromium.app: Chromium.app= 159621120 bytes
RESULT chrome-si: initializers= 0 files

[loyso (OOO), 2015-07-17 04:11:44]

https://build.chromium.org/p/chromium/builders/Mac/