Index: third_party/WebKit/Source/core/fileapi/FileReader.cpp |
diff --git a/third_party/WebKit/Source/core/fileapi/FileReader.cpp b/third_party/WebKit/Source/core/fileapi/FileReader.cpp |
index c983c37d5ef4e9fbfab04291bcd09e8694ee46c6..cbb664b3be518c7ab55d0d99133a40f77808e233 100644 |
--- a/third_party/WebKit/Source/core/fileapi/FileReader.cpp |
+++ b/third_party/WebKit/Source/core/fileapi/FileReader.cpp |
@@ -370,10 +370,19 @@ void FileReader::result(StringOrArrayBuffer& resultAttribute) const |
if (!m_loader || m_error) |
return; |
- if (m_readType == FileReaderLoader::ReadAsArrayBuffer) |
- resultAttribute.setArrayBuffer(m_loader->arrayBufferResult()); |
- else |
+ if (m_readType == FileReaderLoader::ReadAsArrayBuffer) { |
+ // FIXME(crbug.com/536816): |
+ // In on-going work for crbug.com/536816 the code was left in this state |
+ // to avoid changing pre-existing behavior, but we may want to revisit |
+ // this code to determine the proper course of action for cases where |
+ // arrayBufferResultOrNull() returns a nullptr, presumably due to a |
+ // memory allocation failure. Would it be aprropriate to throw a |
+ // RangeError DOM exception from here? Should we cancel the setting |
+ // of resultAttribute instead of setting it to null? |
+ resultAttribute.setArrayBuffer(m_loader->arrayBufferResultOrNull()); |
+ } else { |
resultAttribute.setString(m_loader->stringResult()); |
+ } |
} |
void FileReader::terminate() |