Replacing allocate bitmap IPC messages with a new Mojo interface.

Replacing the AllocateBitmap related IPC messages with new mojo methods in the
RenderMessageFilter interface (it has to be part of the associated interface for
now because of ordering issue with other CC messages).

As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.
Also moved ChildSharedBitmapManager from the ChildThreadImpl to RenderThreadImpl
as it is not common to all child processes.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.

Committed: https://crrev.com/97235f8be07b5fe9200fe76901d27833325a5996
Cr-Commit-Position: refs/heads/master@{#436095}

[Jay Civelli, 2016-11-09 21:32:59]

Description was changed from

==========
Changing allocate bitmap IPC to Mojo.

Replacing the AllocateBitmap related IPC messages with a new mojo
interface (that will also be used for other allocation related
messages).
As part of that unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.

BUG=
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

to

==========
Replacing the AllocateBitmap related IPC messages with a new mojo
interface (that will also be used for other allocation related
messages).
As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

[Jay Civelli, 2016-11-09 21:32:59]

jcivelli@chromium.org changed reviewers:
+ jbauman@chromium.org, rockot@chromium.org

[Jay Civelli, 2016-11-09 21:47:11]

https://codereview.chromium.org/2488913003/diff/20001/content/child/child_sha...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/20001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:188: true /* read_only */);
@jbauman Existing code does not share the memory as read only, but my (limited)
understanding is that it will only be read from the browser/gpu process. Do you
know if that's correct?

[Jay Civelli, 2016-11-09 21:47:18]

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

[commit-bot: I haz the power, 2016-11-09 21:47:47]

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

[jbauman, 2016-11-09 22:26:31]

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:28: scoped_refptr<ThreadSafeSender>
sender,
This sender could be removed.

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:50:
base::WeakPtr<ChildSharedBitmapManager> manager_;
Shared Bitmaps can be allocated and deleted on any thread, so this isn't
thread-safe.

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:86: // different thread (the
compositor thread). We'll bind the ptr on the first
These could also be allocated on the main thread by e.g.
PepperGraphics2DHost::PrepareTextureMailbox

[commit-bot: I haz the power, 2016-11-09 22:35:31]

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

[commit-bot: I haz the power, 2016-11-09 22:35:32]

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

[Jay Civelli, 2016-11-23 16:56:50]

Description was changed from

==========
Replacing the AllocateBitmap related IPC messages with a new mojo
interface (that will also be used for other allocation related
messages).
As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

to

==========
Replacing the AllocateBitmap related IPC messages with new mojo methods in the 
RenderMessageFilter interface (it has to be part of the associated interface for
now because of ordering issue with other CC messages).

As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.
Also moved ChildSharedBitmapManager from the ChildThreadImpl to RenderThreadImpl
as it is not common to all child processes.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

[Jay Civelli, 2016-11-29 16:43:10]

Ready for review again, now that the Mojo thread safe interface ptr code has
landed.

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:28: scoped_refptr<ThreadSafeSender>
sender,
On 2016/11/09 22:26:31, jbauman wrote:
> This sender could be removed.

Now replaced with the thread safe interface ptr.

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:50:
base::WeakPtr<ChildSharedBitmapManager> manager_;
On 2016/11/09 22:26:31, jbauman wrote:
> Shared Bitmaps can be allocated and deleted on any thread, so this isn't
> thread-safe.

Now using a thread safe InterfacePtr.

https://codereview.chromium.org/2488913003/diff/40001/content/child/child_sha...
content/child/child_shared_bitmap_manager.cc:86: // different thread (the
compositor thread). We'll bind the ptr on the first
On 2016/11/09 22:26:31, jbauman wrote:
> These could also be allocated on the main thread by e.g.
> PepperGraphics2DHost::PrepareTextureMailbox

Now that we are using a thread safe interface ptr, this comment is not really
useful, removed.

[Jay Civelli, 2016-11-29 16:43:18]

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

[commit-bot: I haz the power, 2016-11-29 16:43:42]

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-29 17:40:15]

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

[commit-bot: I haz the power, 2016-11-29 17:40:16]

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

[Ken Rockot(use gerrit already), 2016-11-29 17:43:11]

https://codereview.chromium.org/2488913003/diff/120001/content/child/child_sh...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/120001/content/child/child_sh...
content/child/child_shared_bitmap_manager.cc:150: base::SharedMemoryHandle
handle_to_send = memory->handle();
This seems to correctly mirror the old behavior, but the old behavior seems
inconsistent across platforms. On POSIX we dup then send the handle, but on
Windows we just send the handle, leaving |memory| with an invalid handle. It's
probably fine because nobody tries using that handle after the fact.

In order to be consistent, I think we should just scrap the ShareToProcess
below, and instead call DuplicateHandle on memory->handle() directly, still
wrapping the result with WrapSharedMemoryHandle.

Sending a mojo shared buffer to another process always does the right thing with
respect to process handle ownership, so ShareToProcess usage should essentially
be phased out as IPCs transition to mojo.

[Jay Civelli, 2016-11-29 18:01:48]

https://codereview.chromium.org/2488913003/diff/120001/content/child/child_sh...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/120001/content/child/child_sh...
content/child/child_shared_bitmap_manager.cc:150: base::SharedMemoryHandle
handle_to_send = memory->handle();
On 2016/11/29 17:43:11, Ken Rockot wrote:
> This seems to correctly mirror the old behavior, but the old behavior seems
> inconsistent across platforms. On POSIX we dup then send the handle, but on
> Windows we just send the handle, leaving |memory| with an invalid handle. It's
> probably fine because nobody tries using that handle after the fact.
> 
> In order to be consistent, I think we should just scrap the ShareToProcess
> below, and instead call DuplicateHandle on memory->handle() directly, still
> wrapping the result with WrapSharedMemoryHandle.
> 
> Sending a mojo shared buffer to another process always does the right thing
with
> respect to process handle ownership, so ShareToProcess usage should
essentially
> be phased out as IPCs transition to mojo.

Good point, done.

[Ken Rockot(use gerrit already), 2016-11-29 18:11:12]

lgtm

[jbauman, 2016-11-29 22:42:09]

https://codereview.chromium.org/2488913003/diff/140001/content/child/child_sh...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/140001/content/child/child_sh...
content/child/child_shared_bitmap_manager.cc:126: std::move(memory), id);
On POSIX we also want to close the SharedMemory here so that it releases its
file descriptor. Otherwise it's likely that it'll run out of fds, particularly
on mac.

[jbauman, 2016-11-29 22:42:57]

On 2016/11/29 22:42:09, jbauman wrote:
>
https://codereview.chromium.org/2488913003/diff/140001/content/child/child_sh...
> File content/child/child_shared_bitmap_manager.cc (right):
> 
>
https://codereview.chromium.org/2488913003/diff/140001/content/child/child_sh...
> content/child/child_shared_bitmap_manager.cc:126: std::move(memory), id);
> On POSIX we also want to close the SharedMemory here so that it releases its
> file descriptor. Otherwise it's likely that it'll run out of fds, particularly
> on mac.

Actually, mac uses mach ports now, so it's probably fine there. But we'd still
have the problem on linux.

[Jay Civelli, 2016-11-30 01:46:19]

https://codereview.chromium.org/2488913003/diff/140001/content/child/child_sh...
File content/child/child_shared_bitmap_manager.cc (right):

https://codereview.chromium.org/2488913003/diff/140001/content/child/child_sh...
content/child/child_shared_bitmap_manager.cc:126: std::move(memory), id);
On 2016/11/29 22:42:09, jbauman wrote:
> On POSIX we also want to close the SharedMemory here so that it releases its
> file descriptor. Otherwise it's likely that it'll run out of fds, particularly
> on mac.

Oh, I see. Didn't realize the mapped memory would stay available after close.
Done.

[jbauman, 2016-11-30 01:48:36]

lgtm

[Jay Civelli, 2016-11-30 01:58:40]

jcivelli@chromium.org changed reviewers:
+ kinuko@chromium.org

[Jay Civelli, 2016-11-30 01:59:05]

Adding @kinuko for content/ OWNER review.

Thanks.

[kinuko, 2016-11-30 05:00:23]

rs'ish lgtm

[Jay Civelli, 2016-11-30 05:18:56]

The CQ bit was checked by jcivelli@chromium.org

[Jay Civelli, 2016-11-30 05:18:57]

The patchset sent to the CQ was uploaded after l-g-t-m from rockot@chromium.org
Link to the patchset: https://codereview.chromium.org/2488913003/#ps160001
(title: "Addressed @jbauman comment")

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

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 06:08:36]

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

[commit-bot: I haz the power, 2016-11-30 06:08:37]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Jay Civelli, 2016-12-02 00:14:52]

The CQ bit was checked by jcivelli@chromium.org

[Jay Civelli, 2016-12-02 00:14:53]

The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org,
rockot@chromium.org, jbauman@chromium.org
Link to the patchset: https://codereview.chromium.org/2488913003/#ps200001
(title: "Synced")

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

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 00:24:04]

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

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

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Jay Civelli, 2016-12-02 00:45:53]

jcivelli@chromium.org changed reviewers:
+ tsepez@chromium.org

[Jay Civelli, 2016-12-02 00:45:54]

Adding @tsepez for OWNER review of:
content/common/child_process_messages.h
content/common/render_message_filter.mojom

Thanks

[Jay Civelli, 2016-12-02 01:40:57]

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

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

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 02:39:49]

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

[commit-bot: I haz the power, 2016-12-02 02:39:50]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-12-02 17:36:08]

OWNERS LGTM

[Jay Civelli, 2016-12-02 20:52:04]

The CQ bit was checked by jcivelli@chromium.org

[Jay Civelli, 2016-12-02 20:52:05]

The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org,
rockot@chromium.org, jbauman@chromium.org
Link to the patchset: https://codereview.chromium.org/2488913003/#ps220001
(title: "Removing now unused IPC messages.")

[commit-bot: I haz the power, 2016-12-02 20:52: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-02 21:31:37]

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

[commit-bot: I haz the power, 2016-12-02 21:31:38]

Failed to apply patch for
content/browser/renderer_host/render_message_filter.cc:
While running git apply --index -p1;
  error: patch failed:
content/browser/renderer_host/render_message_filter.cc:196
  error: content/browser/renderer_host/render_message_filter.cc: patch does not
apply

Patch:       content/browser/renderer_host/render_message_filter.cc
Index: content/browser/renderer_host/render_message_filter.cc
diff --git a/content/browser/renderer_host/render_message_filter.cc
b/content/browser/renderer_host/render_message_filter.cc
index
89e04e207f4fc5e979f595edb24b13fb2ba5a81b..0256b3a3e2d7f63f54c762454d2a77316bdc9519
100644
--- a/content/browser/renderer_host/render_message_filter.cc
+++ b/content/browser/renderer_host/render_message_filter.cc
@@ -44,7 +44,6 @@
 #include "content/common/child_process_host_impl.h"
 #include "content/common/child_process_messages.h"
 #include "content/common/content_constants_internal.h"
-#include "content/common/host_shared_bitmap_manager.h"
 #include "content/common/render_message_filter.mojom.h"
 #include "content/common/render_process_messages.h"
 #include "content/common/view_messages.h"
@@ -61,6 +60,7 @@
 #include "ipc/ipc_channel_handle.h"
 #include "ipc/ipc_platform_file.h"
 #include "media/base/media_log_event.h"
+#include "mojo/public/cpp/system/platform_handle.h"
 #include "net/base/io_buffer.h"
 #include "net/base/keygen_handler.h"
 #include "net/base/mime_util.h"
@@ -186,8 +186,6 @@ bool RenderMessageFilter::OnMessageReceived(const
IPC::Message& message) {
     // handled here for renderer processes. For non-renderer child processes,
     // they are handled in ChildProcessHostImpl.
     IPC_MESSAGE_HANDLER_DELAY_REPLY(
-        ChildProcessHostMsg_SyncAllocateSharedBitmap, OnAllocateSharedBitmap)
-    IPC_MESSAGE_HANDLER_DELAY_REPLY(
         ChildProcessHostMsg_SyncAllocateGpuMemoryBuffer,
         OnAllocateGpuMemoryBuffer)
     IPC_MESSAGE_HANDLER_DELAY_REPLY(ChildProcessHostMsg_EstablishGpuChannel,
@@ -196,10 +194,6 @@ bool RenderMessageFilter::OnMessageReceived(const
IPC::Message& message) {
                                     OnHasGpuProcess)
     IPC_MESSAGE_HANDLER(ChildProcessHostMsg_DeletedGpuMemoryBuffer,
                         OnDeletedGpuMemoryBuffer)
-    IPC_MESSAGE_HANDLER(ChildProcessHostMsg_AllocatedSharedBitmap,
-                        OnAllocatedSharedBitmap)
-    IPC_MESSAGE_HANDLER(ChildProcessHostMsg_DeletedSharedBitmap,
-                        OnDeletedSharedBitmap)
     IPC_MESSAGE_HANDLER_DELAY_REPLY(
         ChildProcessHostMsg_SyncAllocateLockedDiscardableSharedMemory,
         OnAllocateLockedDiscardableSharedMemory)
@@ -333,39 +327,18 @@ void RenderMessageFilter::SendLoadFontReply(IPC::Message*
reply,
 
 #endif  // defined(OS_MACOSX)
 
-void RenderMessageFilter::AllocateSharedBitmapOnFileThread(
-    uint32_t buffer_size,
-    const cc::SharedBitmapId& id,
-    IPC::Message* reply_msg) {
-  base::SharedMemoryHandle handle;
-  bitmap_manager_client_.AllocateSharedBitmapForChild(PeerHandle(),
buffer_size,
-                                                      id, &handle);
-  ChildProcessHostMsg_SyncAllocateSharedBitmap::WriteReplyParams(reply_msg,
-                                                                 handle);
-  Send(reply_msg);
-}
-
-void RenderMessageFilter::OnAllocateSharedBitmap(uint32_t buffer_size,
-                                                 const cc::SharedBitmapId& id,
-                                                 IPC::Message* reply_msg) {
-  BrowserThread::PostTask(
-      BrowserThread::FILE_USER_BLOCKING,
-      FROM_HERE,
-      base::Bind(&RenderMessageFilter::AllocateSharedBitmapOnFileThread,
-                 this,
-                 buffer_size,
-                 id,
-                 reply_msg));
-}
-
-void RenderMessageFilter::OnAllocatedSharedBitmap(
-    size_t buffer_size,
-    const base::SharedMemoryHandle& handle,
+void RenderMessageFilter::AllocatedSharedBitmap(
+    mojo::ScopedSharedBufferHandle buffer,
     const cc::SharedBitmapId& id) {
-  bitmap_manager_client_.ChildAllocatedSharedBitmap(buffer_size, handle, id);
+  base::SharedMemoryHandle memory_handle;
+  size_t size;
+  MojoResult result = mojo::UnwrapSharedMemoryHandle(
+      std::move(buffer), &memory_handle, &size, NULL);
+  DCHECK_EQ(result, MOJO_RESULT_OK);
+  bitmap_manager_client_.ChildAllocatedSharedBitmap(size, memory_handle, id);
 }
 
-void RenderMessageFilter::OnDeletedSharedBitmap(const cc::SharedBitmapId& id) {
+void RenderMessageFilter::DeletedSharedBitmap(const cc::SharedBitmapId& id) {
   bitmap_manager_client_.ChildDeletedSharedBitmap(id);
 }

[Jay Civelli, 2016-12-02 22:28:00]

The CQ bit was checked by jcivelli@chromium.org

[Jay Civelli, 2016-12-02 22:28:01]

The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org,
rockot@chromium.org, jbauman@chromium.org, tsepez@chromium.org
Link to the patchset: https://codereview.chromium.org/2488913003/#ps240001
(title: "Synced")

[commit-bot: I haz the power, 2016-12-02 22:28:44]

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-03 00:22:04]

CQ is committing da patch.

Bot data: {"patchset_id": 240001, "attempt_start_ts": 1480717680460320,
"parent_rev": "7ba1491ab6419c05cd8de3b7ac9022b40c4295e3", "commit_rev":
"1f7412c3f1f12e078daccea3b6ff126c660a9af9"}

[commit-bot: I haz the power, 2016-12-03 00:22:30]

Description was changed from

==========
Replacing the AllocateBitmap related IPC messages with new mojo methods in the 
RenderMessageFilter interface (it has to be part of the associated interface for
now because of ordering issue with other CC messages).

As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.
Also moved ChildSharedBitmapManager from the ChildThreadImpl to RenderThreadImpl
as it is not common to all child processes.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

to

==========
Replacing the AllocateBitmap related IPC messages with new mojo methods in the 
RenderMessageFilter interface (it has to be part of the associated interface for
now because of ordering issue with other CC messages).

As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.
Also moved ChildSharedBitmapManager from the ChildThreadImpl to RenderThreadImpl
as it is not common to all child processes.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

[commit-bot: I haz the power, 2016-12-03 00:22:31]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-12-03 00:25:57]

Description was changed from

==========
Replacing the AllocateBitmap related IPC messages with new mojo methods in the 
RenderMessageFilter interface (it has to be part of the associated interface for
now because of ordering issue with other CC messages).

As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.
Also moved ChildSharedBitmapManager from the ChildThreadImpl to RenderThreadImpl
as it is not common to all child processes.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.
==========

to

==========
Replacing the AllocateBitmap related IPC messages with new mojo methods in the
RenderMessageFilter interface (it has to be part of the associated interface for
now because of ordering issue with other CC messages).

As part of that, unified the bitmap allocation behavior in
ChildSharedBitmapManager on all platforms, by allocating shared memory
with the generic shared memory allocation code path and then
registering it as a bitmap.
Also moved ChildSharedBitmapManager from the ChildThreadImpl to RenderThreadImpl
as it is not common to all child processes.

BUG=612500
TEST=content_shell should run normally with the --dissable-gpu flag.

Committed: https://crrev.com/97235f8be07b5fe9200fe76901d27833325a5996
Cr-Commit-Position: refs/heads/master@{#436095}
==========

[commit-bot: I haz the power, 2016-12-03 00:26:01]

Patchset 13 (id:??) landed as
https://crrev.com/97235f8be07b5fe9200fe76901d27833325a5996
Cr-Commit-Position: refs/heads/master@{#436095}

[Jay Civelli, 2016-12-06 16:44:51]

A revert of this CL (patchset #13 id:240001) has been created in
https://codereview.chromium.org/2552913003/ by jcivelli@chromium.org.

The reason for reverting is: Might be causing a crasher on Windows.
http://crbug.com/671459.