CSP: 'sandbox' should be ignored in report-only mode.

This is the behavior Firefox is running with[1], and has recently been
explicitly clarified in the spec[2].

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=671389
[2]: https://github.com/w3c/webappsec/commit/2cc237a696e982be59886c8f2ba0ed2d84f22c81

BUG=335489

Review URL: https://codereview.chromium.org/133073007

git-svn-id: svn://svn.chromium.org/blink/trunk@165322 bbb929c8-8fbe-4397-9dbb-9b2b20218538
DevTools: Unify tab view focusing behavior on tab selection and drawer opening

R=pfeldman, vsevik

Review URL: https://codereview.chromium.org/132963005

git-svn-id: svn://svn.chromium.org/blink/trunk@165323 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[GenerateVisitDOMWrapper] should use SetReferenceFromGroup instead of SetObjectGroupId

Given:

  [GenerateVisitDOMWrapper=ownerNode] interface HTMLOptionsCollection { ... }

This means that HTMLOptionsCollection's wrapper should be kept alive if the object group of HTMLOptionsCollection::ownerNode() is alive. On the other hand, this does *not* mean that the object group of HTMLOptionsCollection::ownerNode() should be kept alive if HTMLOptionsCollection's wrapper is alive.

The above fact means that we should use SetReferenceFromGroup instead of SetObjectGroupId. SetReferenceFromGroup adds a reference from the object group to the wrapper, whereas SetObjectGroupId adds bi-directional references between the object group and the wrapper.

(In this particular case of HTMLOptionsCollection and other DOM objects that are using [GenerateVisitDOMWrapper], I don't see any harm in adding bi-directional references. However, it's not nice to add unnecessary lifetime dependency. So this CL fixes them.)

Review URL: https://codereview.chromium.org/116093008

git-svn-id: svn://svn.chromium.org/blink/trunk@165324 bbb929c8-8fbe-4397-9dbb-9b2b20218538