Issue 698142 has been merged into this issue.

Users experienced this crash on the following builds:

Win Canary 58.0.3028.0 -  0.42 CPM, 9 reports, 9 clients (signature blink::DOMArrayBuffer::createUninitialized)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Users experienced this crash on the following builds:

Win Canary 59.0.3030.0 -  0.40 CPM, 2 reports, 2 clients (signature blink::DOMArrayBuffer::createUninitialized)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

bugdroid is either a bit slow or unwilling to update this issue... but addressed via https://codereview.chromium.org/2730943002/

Duped Issue 698142 in C#1 has crash instances seen on M-58 branch as well. Fix CL(https://codereview.chromium.org/2730943002/) landed after branch point so the CL needs to be merged to M-58 as well.

sigbjornf@: Could you please get this merged to M-58 as well.

Note: There have been no crashes seen on the last 2 canary(59.0.3036.0 & 59.0.3037.0) as per Issue 698142.

This is not addressing a regression in any way, just implementing what the spec now allows us to.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bca295bdd893a0217dd4ac32e61eccc08c83ab2

commit 0bca295bdd893a0217dd4ac32e61eccc08c83ab2
Author: Sigbjorn Finne <sigbjornf@opera.com>
Date: Tue Mar 14 12:14:15 2017

XMLHttpRequest: return null upon failing responseArrayBuffer allocation.

The allocation of a response ArrayBuffer may fail, a large enough
contiguous chunk of memory simply not being available from the
underlying allocator. The spec [1] now admits allocation failure as a
possibility, allowing the return of a null buffer if so.

Update our implementation accordingly, returning null rather than
failing hard with an OOM.

1 - https://xhr.spec.whatwg.org/#arraybuffer-response

R=haraken,yhirano
BUG= 673211 

Review-Url: https://codereview.chromium.org/2730943002
Cr-Commit-Position: refs/heads/master@{#455398}
(cherry picked from commit 7c838d986a3d95e81971ef40050fecce0ea2be2c)

Review-Url: https://codereview.chromium.org/2748933003 .
Cr-Commit-Position: refs/branch-heads/3029@{#185}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/core/dom/DOMArrayBuffer.cpp
[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/core/dom/DOMArrayBuffer.h
[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/core/mojo/MojoHandle.cpp
[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/core/testing/Internals.cpp
[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp
[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.h
[modify] https://crrev.com/0bca295bdd893a0217dd4ac32e61eccc08c83ab2/third_party/WebKit/Source/wtf/typed_arrays/ArrayBuffer.h