The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/df6434db4fb6f58af26c25696f19332853938288
commit df6434db4fb6f58af26c25696f19332853938288
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Thu Jun 15 21:35:09 2017
[Extensions] Update DeclarativeApiTest.DeclarativeApi
The DeclarativeApiTest.DeclarativeApi test exercises calling invalid
invocations of [declarativeEvent].getRules() and removeRules(). However,
the "invalid" invocations they have been using simply omit the first
parameter, which is a filter. In the documentation and the schema, this
first parameter is listed as *optional*, and in extension APIs, omitted
optional parameters are allowed. Thus, this is contradictory.
This happens because the get/removeRules functions are defined in
event.js and take two named parameters, using those for validation,
rather than validating on the `arguments` property. Native bindings
actually do the right thing here, and allow the invocation.
Update the test to use truly invalid invocations for the invalid
invocations tests, and add a (disabled) test for using getRules with an
omitted filter.
BUG=733764
BUG=653596
Review-Url: https://codereview.chromium.org/2940133002
Cr-Commit-Position: refs/heads/master@{#479846}
[modify] https://crrev.com/df6434db4fb6f58af26c25696f19332853938288/chrome/test/data/extensions/api_test/declarative/api/background.js
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/d8b910868da66ce4dfba38ff809aaf9704ab0d22
commit d8b910868da66ce4dfba38ff809aaf9704ab0d22
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Wed Aug 02 02:21:57 2017
[Extensions Bindings] Handle a null script context for message logging
Custom bindings can sometimes run after a context is destroyed. This is
almost certainly undesirable, but tracing down each instance when it
happens might be tricky. One guaranteed instance is messaging bindings
performing port cleanup. If a port is cleaned up after the context is
destroyed, an exception will be thrown, which is caught and then logged
to the console. Console logging itself normally expects a script
context, but in this case there is none.
Gracefully handle this by allowing a null script context in console
logging, rather than CHECKing the result (console::AddMessage already
handles a null script context). Ideally, we should fix these to not
have any JS code running after the script context is removed; add a
TODO to that effect.
Note: the null script context behavior happens in both native and JS
bindings; the native bindings just CHECK'd the result.
This makes MessagingApiTest.MessagingBackgroundOnly pass with
native bindings.
--gtest_filter=MessagingApiTest.MessagingBackgroundOnly \
--native-crx-bindings=1
Bug: 653596
Test: browser_tests \
Change-Id: Ie80da8f95cdee9dafe768b101116d116d2931404
Reviewed-on: https://chromium-review.googlesource.com/592390
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491226}
[modify] https://crrev.com/d8b910868da66ce4dfba38ff809aaf9704ab0d22/extensions/renderer/native_extension_bindings_system.cc
The new system is fully functional and has been in finch for awhile now. I'm closing this out in favor of the launch bug (to track stable launch) and smaller bugs to track conversion for the long tail of files and any new issues that crop up.
