Serialize Notification.direction == "auto" in the database (2/3)

Serialize Notification.direction == "auto" in the database (2/3)

This plumbs through the "auto" value, stores it and makes it possible to
return it to Blink once again as well. Blink does not yet pass this
value up to Chromium.

This CL builds on https://codereview.chromium.org/1261783003/. Usage
will be introduced in https://codereview.chromium.org/1260793007/.

BUG=516339
Committed: https://crrev.com/aaa9ca53c284754e12239732221c898a5800e0c7
Cr-Commit-Position: refs/heads/master@{#341722}

[johnme, 2015-08-03 16:17:27]

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

[johnme, 2015-08-03 16:17:28]

lgtm

[Peter Beverloo, 2015-08-03 16:25:46]

peter@chromium.org changed reviewers:
+ avi@chromium.org, palmer@chromium.org

[Peter Beverloo, 2015-08-03 16:25:46]

+avi for //content/public
+palmer for IPC (very trivial)

[Avi (use Gerrit), 2015-08-03 16:34:46]

lgtm

[palmer, 2015-08-03 20:42:46]

IPC security LGTM. Consider adding negative tests.

https://codereview.chromium.org/1262023003/diff/20001/content/browser/notific...
File content/browser/notifications/notification_database_data_unittest.cc
(right):

https://codereview.chromium.org/1262023003/diff/20001/content/browser/notific...
content/browser/notifications/notification_database_data_unittest.cc:93:
PlatformNotificationData::DIRECTION_AUTO
Might be good to add a negative test case.

https://codereview.chromium.org/1262023003/diff/20001/content/child/notificat...
File content/child/notifications/notification_data_conversions_unittest.cc
(right):

https://codereview.chromium.org/1262023003/diff/20001/content/child/notificat...
content/child/notifications/notification_data_conversions_unittest.cc:113:
PlatformNotificationData::DIRECTION_AUTO;
Maybe a negative test case.

[Peter Beverloo, 2015-08-04 13:33:56]

Thanks for the review, Chris! I have acknowledged your suggestion, but have not
put through a change. If you feel strongly, I can do so in a follow-up.

By handling all defined values in the switch() case, we get compile-time
validation that all options have been handled. This is the case for both
converters. None of the switch() statement cases would hit, so we'd effectively
have a test for verifying the default value (which is LTR). I don't think that's
very useful.

Orthogonal to that, if we assume that *anything* in the renderer can be
compromised, then the entire conversion method does not matter - it could be
changed afterwards. When send to the browser process, the
IPC_ENUM_TRAITS_MAX_VALUE trait on the value enforces it to be in range of [0,
*_LAST], so whatever value we receive there is guaranteed to be in-range. I
don't feel it's up to the individual features to test the IPC traits either
(unless they're custom ones, of course).

Putting this on the queue.

[Peter Beverloo, 2015-08-04 13:34:05]

The CQ bit was checked by peter@chromium.org

[commit-bot: I haz the power, 2015-08-04 13:34:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1262023003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1262023003/20001

[commit-bot: I haz the power, 2015-08-04 14:53:52]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-08-04 14:57:13]

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