Use per-frame task runner in XHR

Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696
Committed: https://crrev.com/f884e370f225e3cb7cde91f08dcc369952c7b863
Cr-Commit-Position: refs/heads/master@{#417230}

[tzik, 2016-08-22 05:28:41]

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

[commit-bot: I haz the power, 2016-08-22 05:28:54]

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-08-22 05:44:42]

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

[commit-bot: I haz the power, 2016-08-22 05:44:43]

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

[tzik, 2016-08-22 05:53:18]

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

[commit-bot: I haz the power, 2016-08-22 05:53:29]

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

[tzik, 2016-08-22 06:52:48]

Description was changed from

==========
Use per-frame task runner in XHR

BUG=
==========

to

==========
Use per-frame task runner in XHR

123456789012345678901234567890123456789012345678901234567890123456789012

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=
==========

[tzik, 2016-08-22 06:52:48]

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

[tzik, 2016-08-22 06:52:58]

PTAL

[haraken, 2016-08-22 07:31:35]

LGTM

Remove the 123456... in the CL description :)

[tzik, 2016-08-22 08:09:29]

Description was changed from

==========
Use per-frame task runner in XHR

123456789012345678901234567890123456789012345678901234567890123456789012

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=
==========

to

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=
==========

[commit-bot: I haz the power, 2016-08-22 08:44:39]

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

[commit-bot: I haz the power, 2016-08-22 08:44:40]

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

[tzik, 2016-08-23 07:31:56]

Description was changed from

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=
==========

to

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696
==========

[tzik, 2016-08-23 07:32:07]

The CQ bit was checked by tzik@chromium.org

[commit-bot: I haz the power, 2016-08-23 07:32:30]

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-08-23 09:27:49]

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

[commit-bot: I haz the power, 2016-08-23 09:27:50]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[tzik, 2016-08-23 15:32:37]

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

[commit-bot: I haz the power, 2016-08-23 15:33:01]

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-08-23 17:24:35]

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

[commit-bot: I haz the power, 2016-08-23 17:24:36]

Dry run: This issue passed the CQ dry run.

[tzik, 2016-08-24 04:37:12]

I updated the CL to fix the test failure. We had to hold a ref to the
WebTaskRunner for TimerBase to ensure it keeps valid while a frame is being
detached. PTAL.

[haraken, 2016-08-24 05:03:22]

On 2016/08/24 04:37:12, tzik wrote:
> I updated the CL to fix the test failure. We had to hold a ref to the
> WebTaskRunner for TimerBase to ensure it keeps valid while a frame is being
> detached. PTAL.

Hmm. Maybe a better fix is to add a 'frame->isNotDetached()' check to
TaskRunnerHelper::get so that it can use the default task runner when the frame
is detached?

[tzik, 2016-08-24 09:28:48]

On 2016/08/24 05:03:22, haraken wrote:
> On 2016/08/24 04:37:12, tzik wrote:
> > I updated the CL to fix the test failure. We had to hold a ref to the
> > WebTaskRunner for TimerBase to ensure it keeps valid while a frame is being
> > detached. PTAL.
> 
> Hmm. Maybe a better fix is to add a 'frame->isNotDetached()' check to
> TaskRunnerHelper::get so that it can use the default task runner when the
frame
> is detached?

We have no way to replace WebTaskRunner after the TimerBase instance is created.
Can we just cancel the event on detach()?

[haraken, 2016-08-24 10:37:28]

haraken@chromium.org changed reviewers:
+ alexclarke@chromium.org, dcheng@chromium.org, skyostil@chromium.org

[haraken, 2016-08-24 10:37:29]

On 2016/08/24 09:28:48, tzik wrote:
> On 2016/08/24 05:03:22, haraken wrote:
> > On 2016/08/24 04:37:12, tzik wrote:
> > > I updated the CL to fix the test failure. We had to hold a ref to the
> > > WebTaskRunner for TimerBase to ensure it keeps valid while a frame is
being
> > > detached. PTAL.
> > 
> > Hmm. Maybe a better fix is to add a 'frame->isNotDetached()' check to
> > TaskRunnerHelper::get so that it can use the default task runner when the
> frame
> > is detached?
> 
> We have no way to replace WebTaskRunner after the TimerBase instance is
created.
> Can we just cancel the event on detach()?

Makes sense. LGTM but let's add a TODO.

We should move WebTaskRunner to Oilpan's heap and replace WebTaskRunner* in
TimerBase with Member<WebTaskRunner>. Then we no longer need to worry about
clone().

To make that happen earlier, it's important to reach consensus about the design
of the cancellable tasks.

+Sami +Alex +Daniel FYI

[Sami, 2016-08-24 13:53:26]

lgtm.

[dcheng, 2016-08-24 23:30:34]

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp
(right):

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp:85:
, m_taskRunner(std::move(taskRunner))
I'm a bit confused why we need to clone() and keep this alive manually. Why is
it not normally a problem (and why wasn't it a problem before)?

[haraken, 2016-08-24 23:51:58]

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp
(right):

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp:85:
, m_taskRunner(std::move(taskRunner))
On 2016/08/24 23:30:34, dcheng wrote:
> I'm a bit confused why we need to clone() and keep this alive manually. Why is
> it not normally a problem (and why wasn't it a problem before)?

It's normally a problem today. Currently we need to call clone() whenever we
store a pointer to the per-frame scheduler on some objects. This issue will be
gone once we move WebTaskRunner to Oilpan's heap and start using
Member<WebTaskRunner>.

In this particular case, it was not a problem before because
Platform::current()->currentThread()->scheduler() is not a per-frame scheduler.
The scheduler keeps alive the underlying task runners until the renderer stops.

[dcheng, 2016-08-25 00:39:40]

On 2016/08/24 23:51:58, haraken wrote:
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> File
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp
> (right):
> 
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp:85:
> , m_taskRunner(std::move(taskRunner))
> On 2016/08/24 23:30:34, dcheng wrote:
> > I'm a bit confused why we need to clone() and keep this alive manually. Why
is
> > it not normally a problem (and why wasn't it a problem before)?
> 
> It's normally a problem today. Currently we need to call clone() whenever we
> store a pointer to the per-frame scheduler on some objects. This issue will be
> gone once we move WebTaskRunner to Oilpan's heap and start using
> Member<WebTaskRunner>.
> 
> In this particular case, it was not a problem before because
> Platform::current()->currentThread()->scheduler() is not a per-frame
scheduler.
> The scheduler keeps alive the underlying task runners until the renderer
stops.

Wow, that's a really subtle distinction. How hard will it be to move
WebTaskRunner to the Oilpan heap?

[haraken, 2016-08-25 00:55:56]

On 2016/08/25 00:39:40, dcheng wrote:
> On 2016/08/24 23:51:58, haraken wrote:
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > File
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp
> > (right):
> > 
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp:85:
> > , m_taskRunner(std::move(taskRunner))
> > On 2016/08/24 23:30:34, dcheng wrote:
> > > I'm a bit confused why we need to clone() and keep this alive manually.
Why
> is
> > > it not normally a problem (and why wasn't it a problem before)?
> > 
> > It's normally a problem today. Currently we need to call clone() whenever we
> > store a pointer to the per-frame scheduler on some objects. This issue will
be
> > gone once we move WebTaskRunner to Oilpan's heap and start using
> > Member<WebTaskRunner>.
> > 
> > In this particular case, it was not a problem before because
> > Platform::current()->currentThread()->scheduler() is not a per-frame
> scheduler.
> > The scheduler keeps alive the underlying task runners until the renderer
> stops.
> 
> Wow, that's a really subtle distinction. How hard will it be to move
> WebTaskRunner to the Oilpan heap?

I don't think that's too hard. Alex is planning to work on it (although he is
now busy with sorting out the cancellable task APIs :-)

Also my plan is to completely remove
Platform::current()->currentThread()->scheduler(). Once we move everything to
TaskRunnerHelper, there will be no user of
Platform::current()->currentThread()->scheduler().

[dcheng, 2016-08-25 01:12:19]

On 2016/08/25 00:55:56, haraken wrote:
> On 2016/08/25 00:39:40, dcheng wrote:
> > On 2016/08/24 23:51:58, haraken wrote:
> > >
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > > File
> > >
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > >
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp:85:
> > > , m_taskRunner(std::move(taskRunner))
> > > On 2016/08/24 23:30:34, dcheng wrote:
> > > > I'm a bit confused why we need to clone() and keep this alive manually.
> Why
> > is
> > > > it not normally a problem (and why wasn't it a problem before)?
> > > 
> > > It's normally a problem today. Currently we need to call clone() whenever
we
> > > store a pointer to the per-frame scheduler on some objects. This issue
will
> be
> > > gone once we move WebTaskRunner to Oilpan's heap and start using
> > > Member<WebTaskRunner>.
> > > 
> > > In this particular case, it was not a problem before because
> > > Platform::current()->currentThread()->scheduler() is not a per-frame
> > scheduler.
> > > The scheduler keeps alive the underlying task runners until the renderer
> > stops.
> > 
> > Wow, that's a really subtle distinction. How hard will it be to move
> > WebTaskRunner to the Oilpan heap?
> 
> I don't think that's too hard. Alex is planning to work on it (although he is
> now busy with sorting out the cancellable task APIs :-)
> 
> Also my plan is to completely remove
> Platform::current()->currentThread()->scheduler(). Once we move everything to
> TaskRunnerHelper, there will be no user of
> Platform::current()->currentThread()->scheduler().

LGTM, hopefully we can get the lifetime stuff sorted out soon.

[haraken, 2016-08-25 02:29:33]

Discussed offline with dcheng.

Would it be an option to make TimerBase own std::unique_ptr<WebTaskRunner> and
call clone()? Once we move WebTaskRunner to Oilpan's heap, we can just replace
it with Member<WebTaskRunner>.

[dcheng, 2016-08-25 04:04:54]

On 2016/08/25 02:29:33, haraken wrote:
> Discussed offline with dcheng.
> 
> Would it be an option to make TimerBase own std::unique_ptr<WebTaskRunner> and
> call clone()? Once we move WebTaskRunner to Oilpan's heap, we can just replace
> it with Member<WebTaskRunner>.

It would also make me feel safer about making changes like
https://codereview.chromium.org/2250553002/ - I wasn't initially aware of the
UaF potential, but now, I'm not sure how much of that CL is safe.

[yhirano, 2016-08-25 04:28:24]

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

[yhirano, 2016-08-25 04:28:25]

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h
(right):

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h:112:
std::unique_ptr<WebTaskRunner> m_taskRunner;
Please add some comments describing why this is needed.

[Sami, 2016-08-25 12:54:52]

On 2016/08/25 02:29:33, haraken wrote:
> Discussed offline with dcheng.
> 
> Would it be an option to make TimerBase own std::unique_ptr<WebTaskRunner> and
> call clone()? Once we move WebTaskRunner to Oilpan's heap, we can just replace
> it with Member<WebTaskRunner>.

I agree that it would make sense for TimerBase to own the task runner.

[tzik, 2016-08-29 02:08:59]

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h
(right):

https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h:112:
std::unique_ptr<WebTaskRunner> m_taskRunner;
On 2016/08/25 04:28:25, yhirano wrote:
> Please add some comments describing why this is needed.

Done.

[haraken, 2016-08-29 02:30:35]

On 2016/08/29 02:08:59, tzik wrote:
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> File
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h
> (right):
> 
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h:112:
> std::unique_ptr<WebTaskRunner> m_taskRunner;
> On 2016/08/25 04:28:25, yhirano wrote:
> > Please add some comments describing why this is needed.
> 
> Done.

Per the discussion in #34, #35 and #38, our plan is to make TimerBase own
std::unique_ptr<WebTaskRunner> instead of landing this CL, right?

[tzik, 2016-08-30 13:13:48]

On 2016/08/29 02:30:35, haraken wrote:
> On 2016/08/29 02:08:59, tzik wrote:
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > File
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h
> > (right):
> > 
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h:112:
> > std::unique_ptr<WebTaskRunner> m_taskRunner;
> > On 2016/08/25 04:28:25, yhirano wrote:
> > > Please add some comments describing why this is needed.
> > 
> > Done.
> 
> Per the discussion in #34, #35 and #38, our plan is to make TimerBase own
> std::unique_ptr<WebTaskRunner> instead of landing this CL, right?

Do we want to do it before this CL...?
OK, I made a separate CL for it: https://codereview.chromium.org/2290243002/

[haraken, 2016-08-30 15:40:36]

On 2016/08/30 13:13:48, tzik wrote:
> On 2016/08/29 02:30:35, haraken wrote:
> > On 2016/08/29 02:08:59, tzik wrote:
> > >
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > > File
> > >
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > >
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h:112:
> > > std::unique_ptr<WebTaskRunner> m_taskRunner;
> > > On 2016/08/25 04:28:25, yhirano wrote:
> > > > Please add some comments describing why this is needed.
> > > 
> > > Done.
> > 
> > Per the discussion in #34, #35 and #38, our plan is to make TimerBase own
> > std::unique_ptr<WebTaskRunner> instead of landing this CL, right?
> 
> Do we want to do it before this CL...?
> OK, I made a separate CL for it: https://codereview.chromium.org/2290243002/

Once you land that CL, PS1 will work, right?

[tzik, 2016-09-06 11:02:25]

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

[commit-bot: I haz the power, 2016-09-06 11:02:33]

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-09-06 12:23:25]

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

[commit-bot: I haz the power, 2016-09-06 12:23:26]

Dry run: This issue passed the CQ dry run.

[tzik, 2016-09-07 13:37:19]

On 2016/08/30 15:40:36, haraken wrote:
> On 2016/08/30 13:13:48, tzik wrote:
> > On 2016/08/29 02:30:35, haraken wrote:
> > > On 2016/08/29 02:08:59, tzik wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > > > File
> > > >
> > >
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h
> > > > (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/2269513002/diff/40001/third_party/WebKit/Sour...
> > > >
> > >
> >
>
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.h:112:
> > > > std::unique_ptr<WebTaskRunner> m_taskRunner;
> > > > On 2016/08/25 04:28:25, yhirano wrote:
> > > > > Please add some comments describing why this is needed.
> > > > 
> > > > Done.
> > > 
> > > Per the discussion in #34, #35 and #38, our plan is to make TimerBase own
> > > std::unique_ptr<WebTaskRunner> instead of landing this CL, right?
> > 
> > Do we want to do it before this CL...?
> > OK, I made a separate CL for it: https://codereview.chromium.org/2290243002/
> 
> Once you land that CL, PS1 will work, right?

Landed the TimerBase CL and reverted this CL to PS1. Is this ready to land now?

[yhirano, 2016-09-07 13:56:22]

lgtm

[haraken, 2016-09-07 14:33:59]

LGTM

[tzik, 2016-09-08 07:28:02]

The CQ bit was checked by tzik@chromium.org

[tzik, 2016-09-08 07:28:03]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org,
skyostil@chromium.org
Link to the patchset: https://codereview.chromium.org/2269513002/#ps80001
(title: "revert to PS1")

[commit-bot: I haz the power, 2016-09-08 07:28:33]

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-09-08 09:12:13]

Description was changed from

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696
==========

to

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696
==========

[commit-bot: I haz the power, 2016-09-08 09:12:15]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-09-08 09:14:04]

Description was changed from

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696
==========

to

==========
Use per-frame task runner in XHR

The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696

Committed: https://crrev.com/f884e370f225e3cb7cde91f08dcc369952c7b863
Cr-Commit-Position: refs/heads/master@{#417230}
==========

[commit-bot: I haz the power, 2016-09-08 09:14:05]

Patchset 5 (id:??) landed as
https://crrev.com/f884e370f225e3cb7cde91f08dcc369952c7b863
Cr-Commit-Position: refs/heads/master@{#417230}

[tzik, 2016-10-11 13:31:18]

A revert of this CL (patchset #5 id:80001) has been created in
https://codereview.chromium.org/2407233002/ by tzik@chromium.org.

The reason for reverting is: Speculative revert for http://crbug.com/645365.
Will reland once it turns out being not the case..