Closed Bug 1286712 Opened 8 years ago Closed 8 years ago

Some content script API parameters are not validated (runtime, i18n)

Categories

(WebExtensions :: Untriaged, defect, P3)

defect

Tracking

(firefox50 affected, firefox51 verified)

VERIFIED FIXED
Tracking Status
firefox50 --- affected
firefox51 --- verified

People

(Reporter: robwu, Assigned: robwu)

References

Details

(Whiteboard: triaged)

Attachments

(3 files)

Attached file content_script_invalid_params.zip (deleted) —
1. Load the attached extension. 2. Visit example.com (the content script calls several APIs with an invalid method signature). 3. Open the console of the tab and look at the printed messages. Expected: OK: Got expected error: Error: Incorrect argument types for storage.StorageArea.get. OK: Got expected error: Error: Incorrect argument types for runtime.connect. OK: Got expected error: Error: Incorrect argument types for runtime.sendMessage. OK: Got expected error: Error: Incorrect argument types for i18n. Actual: OK: Got expected error: Error: Incorrect argument types for storage.StorageArea.get. FAIL: Expected a parameter validation error for runtime.connect API FAIL: Expected a parameter validation error for runtime.sendMessage API FAIL: Expected a parameter validation error for i18n API Note: The background page seems to not validate chrome.runtime.sendMessage's parameters. When I run the content script as a background script, the background console contains: OK: Got expected error: Error: Incorrect argument types for storage.StorageArea.get. OK: Got expected error: Error: Incorrect argument types for runtime.connect. FAIL: Expected a parameter validation error for runtime.sendMessage API OK: Got expected error: Error: Incorrect argument types for i18n. Extra info: There is a unit test for validating the params of runtime.connect in background pages, this test can be re-used for content scripts when you fix the bug. toolkit/components/extensions/test/mochitest/test_ext_background_runtime_connect_params.html
Priority: -- → P3
Whiteboard: triaged
The validation issues for connect and i18n will be resolved by bug 1287007. Schema-based parameter validation is disabled for runtime.sendMessage due to the allowAmbiguousOptionalArguments flag, so that has to be addressed separately.
Depends on: 1287007
Attachment #8782268 - Flags: review?(wmccloskey)
Attachment #8782269 - Flags: review?(wmccloskey)
Comment on attachment 8782268 [details] Bug 1286712 - Validate runtime.sendMessage parameters https://reviewboard.mozilla.org/r/72464/#review70468 ::: toolkit/components/extensions/test/xpcshell/test_ext_runtime_sendMessage_errors.js:9 (Diff revision 1) > + > +add_task(function* test_sendMessage_error() { > + function background() { > + let circ = {}; > + circ.circ = circ; > + let testCases = [ Can you do some tests passing in undefined?
Attachment #8782268 - Flags: review?(wmccloskey) → review+
Comment on attachment 8782269 [details] Bug 1286712 - Remove unused ExtensionContext and GlobalManager globals https://reviewboard.mozilla.org/r/72466/#review70474
Attachment #8782269 - Flags: review?(wmccloskey) → review+
Assignee: nobody → rob
Status: NEW → ASSIGNED
Second commit message is missing the bug number.
Keywords: checkin-needed
Updated commit description as requested. Also updated dependency - with the fixes for bug 1287010, this bug would be fixed as well.
Depends on: 1287010
No longer depends on: 1287007
Keywords: checkin-needed
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/autoland/rev/99d6e016dcef Validate runtime.sendMessage parameters r=billm https://hg.mozilla.org/integration/autoland/rev/7ad45b51d189 Remove unused ExtensionContext and GlobalManager globals r=billm
Keywords: checkin-needed
Verified fixed in Firefox 51.0a1 (2016-08-25) using the manual test from the report. The test case still shows "FAIL: Expected a parameter validation error for runtime.sendMessage API", but that's because it only tests for synchronously thrown errors. The global console shows "Error: runtime.sendMessage received too many arguments", which is what I'd expect.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
I’ve also confirm that the expected results mentioned in Comment 15 are encountered in Firefox 51.0a1 (2016-09-12) under Windows 10 64-bit.
Status: RESOLVED → VERIFIED
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: