The current tests do not test for the case where useContentScriptContext is set true by the developer but there is no security origin matching content script context. When such a test is added, it becomes apparent that the error for option processing are not returned to the client of evaluate(). Patch ready
The bad-option test on the patch for bug 106811 cannot pass without a fix to this bug.
Created attachment 186436 [details] Patch
Comment on attachment 186436 [details] Patch Attachment 186436 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16365456 New failing tests: inspector/extensions/extensions-eval-content-script-bad-option.html
Comment on attachment 186436 [details] Patch Attachment 186436 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16366508 New failing tests: inspector/extensions/extensions-eval-content-script-bad-option.html
Comment on attachment 186436 [details] Patch Attachment 186436 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16366511 New failing tests: inspector/extensions/extensions-eval-content-script-bad-option.html
Comment on attachment 186436 [details] Patch I don't think we should invoke the callback wrapper passing it the text error message. Besides, returning value from the message handler already results in dispatching the error to the client. See also bug 108640.
Comment on attachment 186436 [details] Patch r- per Andrey's comment.