Fix localstorage data migration.

content/browser/dom_storage/local_storage_context_mojo_unittest.cc

Index: content/browser/dom_storage/local_storage_context_mojo_unittest.cc
diff --git a/content/browser/dom_storage/local_storage_context_mojo_unittest.cc b/content/browser/dom_storage/local_storage_context_mojo_unittest.cc
index b22117d7e4efa515ecaa79e787f3f38cee167d21..90e4a79fe2b99893f8f4e97e0e058700305b592f 100644
--- a/content/browser/dom_storage/local_storage_context_mojo_unittest.cc
+++ b/content/browser/dom_storage/local_storage_context_mojo_unittest.cc
@@ -64,7 +64,11 @@ void NoOpGet(bool success, const std::vector<uint8_t>& value) {}
 
 std::vector<uint8_t> String16ToUint8Vector(const base::string16& input) {
   const uint8_t* data = reinterpret_cast<const uint8_t*>(input.data());
-  return std::vector<uint8_t>(data, data + input.size() * sizeof(base::char16));
+  std::vector<uint8_t> result;
+  result.reserve(input.size() * sizeof(base::char16) + 1);
+  result.push_back(0);
+  result.insert(result.end(), data, data + input.size() * sizeof(base::char16));

[michaeln, 2017/03/22 23:49:51]

ditto comment about sharing 'format' enum or encode function in some way, maybe
put StorageFormat enum in common/dom_storage_types.h?

also, i'm just noticing these databases aren't portable in the endianness sense,
do we care about that?

[Marijn Kruisselbrink, 2017/03/31 23:06:14]

And I changed it so at least the test here shares the encoding function with
LocalStorageContextMojo by adding it as a static function there.
I think we're okay not being portable endianness wise? But yeah, that's a good
question. I thought somebody said SerializedScriptValue (i.e. indexeddb) isn't
endian safe either, but I'm not sure about that...

+  return result;
 }
 
 class TestLevelDBObserver : public mojom::LevelDBObserver {