Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2151693002:
Fix extension bindings injection for iframes (Closed)
|
Created:
4 years, 5 months ago by asargent_no_longer_on_chrome Modified:
4 years, 5 months ago Reviewers:
Devlin CC:
chromium-reviews, chromium-apps-reviews_chromium.org, extensions-reviews_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionFix extension bindings injection for iframes
For iframes, we don't want to use the source url for determining the
associated extension because it starts out with an about:blank context
that is scriptable by its parent.
BUG=573131
Committed: https://crrev.com/91f655b19888da3f86b57ad8c548da93e7b9aba4
Cr-Commit-Position: refs/heads/master@{#407214}
Patch Set 1 #
Total comments: 11
Patch Set 2 : use security origin, augmented tests, fix nits #
Total comments: 16
Patch Set 3 : more review fixes #
Total comments: 1
Patch Set 4 : hacker_case -> camelCase #
Total comments: 6
Patch Set 5 : more fixes from review feedback #Messages
Total messages: 24 (9 generated)
asargent@chromium.org changed reviewers: + rdevlin.cronin@chromium.org
https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... extensions/renderer/script_context_set.cc:151: GURL frame_url = frame->parent() Hmm... so what happens if the web page opens a popup and then navigates it? In that case, I think the parent() would be null, but its opener would still be the current page, so I think scripting would still be allowed, right?
https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... extensions/renderer/script_context_set.cc:151: GURL frame_url = frame->parent() On 2016/07/13 23:19:09, Devlin wrote: > Hmm... so what happens if the web page opens a popup and then navigates it? In > that case, I think the parent() would be null, but its opener would still be the > current page, so I think scripting would still be allowed, right? I just double-checked that using a new window does not have the vulnerability, but I need to look more closely to explain why - it might be because new windows don't get the same "briefly create an about:blank script context and allow parent to script it" behavior that iframes get. I may also add a test for this.
https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... File chrome/test/data/extensions/api_test/bindings/external_message_listener/background.js (right): https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... chrome/test/data/extensions/api_test/bindings/external_message_listener/background.js:9: if (msg == "from_sender") { prefer single quotes in JS https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... File chrome/test/data/extensions/api_test/bindings/iframe_before_navigate.html (right): https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... chrome/test/data/extensions/api_test/bindings/iframe_before_navigate.html:5: <script> due to the semi-ambiguous ordering of when blink creates the document vs executes the script, it might be worth also adding a test for an iframe that's created directly in the script tag. Otherwise, it might be possible that by the time the script runs, the iframe has already navigated from about:blank. It could also be worth trying with a frame that points to a non-existent resource, since we've had bugs around treating them differently. I'd probably just have four frames, one real and fake resource for each specified in the document and created in the script, and then try with all of them. None of them should succeed. https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... chrome/test/data/extensions/api_test/bindings/iframe_before_navigate.html:17: window.domAutomationController.send(didRun && typeof(id) == "undefined"); typeof is an operator, not a function, so this should be "typeof id" https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... extensions/renderer/script_context_set.cc:151: GURL frame_url = frame->parent() On 2016/07/14 16:38:30, Antony Sargent wrote: > On 2016/07/13 23:19:09, Devlin wrote: > > Hmm... so what happens if the web page opens a popup and then navigates it? > In > > that case, I think the parent() would be null, but its opener would still be > the > > current page, so I think scripting would still be allowed, right? > > I just double-checked that using a new window does not have the vulnerability, > but I need to look more closely to explain why - it might be because new windows > don't get the same "briefly create an about:blank script context and allow > parent to script it" behavior that iframes get. I may also add a test for this. As long as we can test and assert that it's the case, we're probably okay. But I'd be very interested to know why it doesn't reproduce.
https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... extensions/renderer/script_context_set.cc:151: GURL frame_url = frame->parent() On 2016/07/14 16:46:35, Devlin wrote: > On 2016/07/14 16:38:30, Antony Sargent wrote: > > On 2016/07/13 23:19:09, Devlin wrote: > > > Hmm... so what happens if the web page opens a popup and then navigates it? > > In > > > that case, I think the parent() would be null, but its opener would still be > > the > > > current page, so I think scripting would still be allowed, right? > > > > I just double-checked that using a new window does not have the vulnerability, > > but I need to look more closely to explain why - it might be because new > windows > > don't get the same "briefly create an about:blank script context and allow > > parent to script it" behavior that iframes get. I may also add a test for > this. > > As long as we can test and assert that it's the case, we're probably okay. But > I'd be very interested to know why it doesn't reproduce. Ok, so the web page is allowed to run script in the new window before it finishes navigation, just like with iframes. But, it turns out that unlike in the case of iframes, the initial WebLocalFrame for the new window's about:blank js context before it does the navigation has a document url that is completely empty (instead of about:blank), and both its data source and provisional data sources have empty urls also. So we end up using the empty string as the frame_url in to the call to GetExtensionOrAppIDByURL below, and this just returns an empty extension_id. The frame just comes to us this way in Dispatcher::DidCreateScriptContext, and I haven't traced through the Blink code to understand why this is the case. But now I'm rethinking the nature of my patch - it fixes the problem but it would be nice to find a way to solve the problem that seems more solid. I'm going to look into possibly using the WebSecurityOrigin instead, since that seems to be more reliable than the url or data source url. The whole effective document url thing below (for implementing about:blank frame matching for context scripts) may complicate things though.
Patchset #2 (id:20001) has been deleted
ptal https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... File chrome/test/data/extensions/api_test/bindings/external_message_listener/background.js (right): https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... chrome/test/data/extensions/api_test/bindings/external_message_listener/background.js:9: if (msg == "from_sender") { On 2016/07/14 16:46:35, Devlin wrote: > prefer single quotes in JS Done. (Here and elsewhere in the CL) https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... File chrome/test/data/extensions/api_test/bindings/iframe_before_navigate.html (right): https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... chrome/test/data/extensions/api_test/bindings/iframe_before_navigate.html:5: <script> On 2016/07/14 16:46:35, Devlin wrote: > due to the semi-ambiguous ordering of when blink creates the document vs > executes the script, it might be worth also adding a test for an iframe that's > created directly in the script tag. Otherwise, it might be possible that by the > time the script runs, the iframe has already navigated from about:blank. > > It could also be worth trying with a frame that points to a non-existent > resource, since we've had bugs around treating them differently. I'd probably > just have four frames, one real and fake resource for each specified in the > document and created in the script, and then try with all of them. None of them > should succeed. Done. Also added tests of existent/nonexisting pages opened via window.open. https://codereview.chromium.org/2151693002/diff/1/chrome/test/data/extensions... chrome/test/data/extensions/api_test/bindings/iframe_before_navigate.html:17: window.domAutomationController.send(didRun && typeof(id) == "undefined"); On 2016/07/14 16:46:35, Devlin wrote: > typeof is an operator, not a function, so this should be "typeof id" Done. https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/1/extensions/renderer/script_... extensions/renderer/script_context_set.cc:151: GURL frame_url = frame->parent() On 2016/07/14 21:38:07, Antony Sargent wrote: > On 2016/07/14 16:46:35, Devlin wrote: > > On 2016/07/14 16:38:30, Antony Sargent wrote: > > > On 2016/07/13 23:19:09, Devlin wrote: > > > > Hmm... so what happens if the web page opens a popup and then navigates > it? > > > In > > > > that case, I think the parent() would be null, but its opener would still > be > > > the > > > > current page, so I think scripting would still be allowed, right? > > > > > > I just double-checked that using a new window does not have the > vulnerability, > > > but I need to look more closely to explain why - it might be because new > > windows > > > don't get the same "briefly create an about:blank script context and allow > > > parent to script it" behavior that iframes get. I may also add a test for > > this. > > > > As long as we can test and assert that it's the case, we're probably okay. > But > > I'd be very interested to know why it doesn't reproduce. > > Ok, so the web page is allowed to run script in the new window before it > finishes navigation, just like with iframes. But, it turns out that unlike in > the case of iframes, the initial WebLocalFrame for the new window's about:blank > js context before it does the navigation has a document url that is completely > empty (instead of about:blank), and both its data source and provisional data > sources have empty urls also. So we end up using the empty string as the > frame_url in to the call to GetExtensionOrAppIDByURL below, and this just > returns an empty extension_id. > > The frame just comes to us this way in Dispatcher::DidCreateScriptContext, and I > haven't traced through the Blink code to understand why this is the case. But > now I'm rethinking the nature of my patch - it fixes the problem but it would be > nice to find a way to solve the problem that seems more solid. I'm going to look > into possibly using the WebSecurityOrigin instead, since that seems to be more > reliable than the url or data source url. The whole effective document url thing > below (for implementing about:blank frame matching for context scripts) may > complicate things though. > > It turned I was able to use the WebSecurityOrigin on the frame, and compare that against the data source url.
Nice! This approach looks much better. :) https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... File chrome/browser/extensions/extension_bindings_apitest.cc (right): https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:213: // chrome-extenison:// urls, both web_accessible and non-existing pages, don't nit: s/non-existing/nonexistent https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:222: base::CommandLine::ForCurrentProcess()->AppendSwitch( Should this be in SetUpCommandLine()? https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:230: sender_ready.set_extension_id(sender->id()); If the listener was satisfied before this point, this criterion has no effect (I wonder if we should DCHECK that in the listener code - or make it work). Since (hopefully) no other extensions are going to send "sender_ready", I think we can remove this line. https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:238: receiver_ready.set_extension_id(receiver->id()); ditto https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:259: // This should cause |sender| to send a real message over to |receiver|, at This part, to me, is just a little more difficult to follow. I wonder if this would be more clear by just using ExecuteScriptAndExtractInt() to get the value of messagesReceived. To me, that seems slightly more straightforward than setting up the callback -> sender, sender message -> receiver, receiver message -> C++ that we have now. WDYT? This isn't that bad as it is now (just struck me as a little harder to grok), so if you prefer this way, that's fine. https://codereview.chromium.org/2151693002/diff/40001/chrome/test/data/extens... File chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html (right): https://codereview.chromium.org/2151693002/diff/40001/chrome/test/data/extens... chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html:8: // We expect that chrome.runtime.id will not be set in this frame, and that either Are some of these lines over 80 char? Or is that just rietveld? https://codereview.chromium.org/2151693002/diff/40001/extensions/renderer/scr... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/40001/extensions/renderer/scr... extensions/renderer/script_context_set.cc:150: GURL frame_url = GURL(frame->document().url()); nit: prefer construction over assignment in a case like this.
Patchset #3 (id:60001) has been deleted
The CQ bit was checked by asargent@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... File chrome/browser/extensions/extension_bindings_apitest.cc (right): https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:213: // chrome-extenison:// urls, both web_accessible and non-existing pages, don't On 2016/07/21 00:44:54, Devlin wrote: > nit: s/non-existing/nonexistent Done. https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:222: base::CommandLine::ForCurrentProcess()->AppendSwitch( On 2016/07/21 00:44:54, Devlin wrote: > Should this be in SetUpCommandLine()? It works fine being here, I think because we don't need the value set until the renderer for the "frames_before_navigate.html" page is created when we open the page below in the test. Also, since we don't need it for the other ExtensionBindingsApiTest tests, if I did put it in a SetUpCommandLine, I'd need to make a new subclass of ExtensionBindingsApiTest. https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:230: sender_ready.set_extension_id(sender->id()); On 2016/07/21 00:44:54, Devlin wrote: > If the listener was satisfied before this point, this criterion has no effect (I > wonder if we should DCHECK that in the listener code - or make it work). Since > (hopefully) no other extensions are going to send "sender_ready", I think we can > remove this line. Good point - I think in early iterations of the test I had been using multiple ExtensionTestMessageListener's with the "listen for any message" feature, so I needed to restrict by id, but that isn't needed anymore. https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:238: receiver_ready.set_extension_id(receiver->id()); On 2016/07/21 00:44:54, Devlin wrote: > ditto Done. https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:259: // This should cause |sender| to send a real message over to |receiver|, at On 2016/07/21 00:44:54, Devlin wrote: > This part, to me, is just a little more difficult to follow. I wonder if this > would be more clear by just using ExecuteScriptAndExtractInt() to get the value > of messagesReceived. > > To me, that seems slightly more straightforward than setting up the callback -> > sender, sender message -> receiver, receiver message -> C++ that we have now. > > WDYT? This isn't that bad as it is now (just struck me as a little harder to > grok), so if you prefer this way, that's fine. I rewrote it using ExecuteScriptAndExtractInt, which does make this part of the C++ code a little simpler. I did have to add a tiny bit of complexity to the existing background.js file of the |receiver|, since we don't want to return the count until after we've received the message from |sender|. Let me know if that seems easier to grok. https://codereview.chromium.org/2151693002/diff/40001/chrome/test/data/extens... File chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html (right): https://codereview.chromium.org/2151693002/diff/40001/chrome/test/data/extens... chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html:8: // We expect that chrome.runtime.id will not be set in this frame, and that either On 2016/07/21 00:44:54, Devlin wrote: > Are some of these lines over 80 char? Or is that just rietveld? Oops, it actually went to 81 chars. Fixed. https://codereview.chromium.org/2151693002/diff/40001/extensions/renderer/scr... File extensions/renderer/script_context_set.cc (right): https://codereview.chromium.org/2151693002/diff/40001/extensions/renderer/scr... extensions/renderer/script_context_set.cc:150: GURL frame_url = GURL(frame->document().url()); On 2016/07/21 00:44:54, Devlin wrote: > nit: prefer construction over assignment in a case like this. Done.
https://codereview.chromium.org/2151693002/diff/80001/chrome/test/data/extens... File chrome/test/data/extensions/api_test/bindings/external_message_listener/background.js (right): https://codereview.chromium.org/2151693002/diff/80001/chrome/test/data/extens... chrome/test/data/extensions/api_test/bindings/external_message_listener/background.js:8: var received_real_sender_message = false; gah, just realized I named this and the var below with hacker_case, not camelCase. I'll upload another patch set with this fixed.
lgtm with nits https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... File chrome/browser/extensions/extension_bindings_apitest.cc (right): https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:222: base::CommandLine::ForCurrentProcess()->AppendSwitch( On 2016/07/21 18:12:22, Antony Sargent wrote: > On 2016/07/21 00:44:54, Devlin wrote: > > Should this be in SetUpCommandLine()? > > It works fine being here, I think because we don't need the value set until the > renderer for the "frames_before_navigate.html" page is created when we open the > page below in the test. Also, since we don't need it for the other > ExtensionBindingsApiTest tests, if I did put it in a SetUpCommandLine, I'd need > to make a new subclass of ExtensionBindingsApiTest. I have two concerns: - If we ever change chrome to cache this command line flag, rather than checking it as we launch a renderer, this will stop working. - If the browser test runs in a different process than chrome, this won't work (I think we do/did/thought about doing this at point? I can't recall.) Since we have the canonical way of modifying the command line through SetUpCommandLine, I'd be more comfortable with the extra 5 lines to subclass ExtensionBindingsApiTest. But I don't feel super strongly, so I'll leave it up to you. https://codereview.chromium.org/2151693002/diff/40001/chrome/browser/extensio... chrome/browser/extensions/extension_bindings_apitest.cc:259: // This should cause |sender| to send a real message over to |receiver|, at On 2016/07/21 18:12:22, Antony Sargent wrote: > On 2016/07/21 00:44:54, Devlin wrote: > > This part, to me, is just a little more difficult to follow. I wonder if this > > would be more clear by just using ExecuteScriptAndExtractInt() to get the > value > > of messagesReceived. > > > > To me, that seems slightly more straightforward than setting up the callback > -> > > sender, sender message -> receiver, receiver message -> C++ that we have now. > > > > WDYT? This isn't that bad as it is now (just struck me as a little harder to > > grok), so if you prefer this way, that's fine. > > I rewrote it using ExecuteScriptAndExtractInt, which does make this part of the > C++ code a little simpler. I did have to add a tiny bit of complexity to the > existing background.js file of the |receiver|, since we don't want to return the > count until after we've received the message from |sender|. Let me know if that > seems easier to grok. Ah, I see, we need this in order to ensure there's no race with when the messages could have been delivered. Got it. https://codereview.chromium.org/2151693002/diff/100001/chrome/browser/extensi... File chrome/browser/extensions/extension_bindings_apitest.cc (right): https://codereview.chromium.org/2151693002/diff/100001/chrome/browser/extensi... chrome/browser/extensions/extension_bindings_apitest.cc:258: int message_count; nit: initialize this. https://codereview.chromium.org/2151693002/diff/100001/chrome/browser/extensi... chrome/browser/extensions/extension_bindings_apitest.cc:260: extensions::ProcessManager::Get(profile()) nit: already in extensions::. https://codereview.chromium.org/2151693002/diff/100001/chrome/test/data/exten... File chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html (right): https://codereview.chromium.org/2151693002/diff/100001/chrome/test/data/exten... chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html:19: win.eval('typeof chrome.runtime != "undefined" && chrome.runtime.sendMessage(' + still over 80 char?
> I have two concerns: > - If we ever change chrome to cache this command line flag, rather than checking > it as we launch a renderer, this will stop working. > - If the browser test runs in a different process than chrome, this won't work > (I think we do/did/thought about doing this at point? I can't recall.) > > Since we have the canonical way of modifying the command line through > SetUpCommandLine, I'd be more comfortable with the extra 5 lines to subclass > ExtensionBindingsApiTest. But I don't feel super strongly, so I'll leave it up > to you. Ok, not that big a deal either way. I moved to having a derived test class with a customized SetUpCommandLine override. https://codereview.chromium.org/2151693002/diff/100001/chrome/browser/extensi... File chrome/browser/extensions/extension_bindings_apitest.cc (right): https://codereview.chromium.org/2151693002/diff/100001/chrome/browser/extensi... chrome/browser/extensions/extension_bindings_apitest.cc:258: int message_count; On 2016/07/21 22:20:34, Devlin wrote: > nit: initialize this. Done. https://codereview.chromium.org/2151693002/diff/100001/chrome/browser/extensi... chrome/browser/extensions/extension_bindings_apitest.cc:260: extensions::ProcessManager::Get(profile()) On 2016/07/21 22:20:34, Devlin wrote: > nit: already in extensions::. Done. https://codereview.chromium.org/2151693002/diff/100001/chrome/test/data/exten... File chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html (right): https://codereview.chromium.org/2151693002/diff/100001/chrome/test/data/exten... chrome/test/data/extensions/api_test/bindings/frames_before_navigation.html:19: win.eval('typeof chrome.runtime != "undefined" && chrome.runtime.sendMessage(' + On 2016/07/21 22:20:34, Devlin wrote: > still over 80 char? Argh, sorry. Done.
Patchset #6 (id:140001) has been deleted
The CQ bit was checked by asargent@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from rdevlin.cronin@chromium.org Link to the patchset: https://codereview.chromium.org/2151693002/#ps120001 (title: "more fixes from review feedback")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #5 (id:120001)
Message was sent while issue was closed.
Description was changed from ========== Fix extension bindings injection for iframes For iframes, we don't want to use the source url for determining the associated extension because it starts out with an about:blank context that is scriptable by its parent. BUG=573131 ========== to ========== Fix extension bindings injection for iframes For iframes, we don't want to use the source url for determining the associated extension because it starts out with an about:blank context that is scriptable by its parent. BUG=573131 Committed: https://crrev.com/91f655b19888da3f86b57ad8c548da93e7b9aba4 Cr-Commit-Position: refs/heads/master@{#407214} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/91f655b19888da3f86b57ad8c548da93e7b9aba4 Cr-Commit-Position: refs/heads/master@{#407214}
Message was sent while issue was closed.
A revert of this CL (patchset #5 id:120001) has been created in https://codereview.chromium.org/2191793002/ by benwells@chromium.org. The reason for reverting is: This Cl caused a test failure under DrMemory. First build with failing test: https://build.chromium.org/p/chromium.memory.fyi/builders/Windows%20Browser%2... Sample failure output: FramesExtensionBindingsApiTest.FramesBeforeNavigation: [1420:4432:0722/173632:WARNING:chrome_browser_main_win.cc(419)] Command line too long for RegisterApplicationRestart [1420:4432:0722/174006:INFO:CONSOLE(0)] "Denying load of chrome-extension://ficgdghpakbhhkmdjamiedmcoobamkoo/nonexistent.html. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.", source: about:blank (0) [1420:4432:0722/174015:INFO:CONSOLE(24)] "caught exception: SecurityError: Blocked a frame with origin "http://127.0.0.1:50285" from accessing a cross-origin frame.", source: http://127.0.0.1:50285/extensions/api_test/bindings/frames_before_navigation.... (24) [1420:4432:0722/174018:INFO:CONSOLE(0)] "Denying load of chrome-extension://ficgdghpakbhhkmdjamiedmcoobamkoo/nonexistent.html. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.", source: about:blank (0) [1420:4988:0722/174053:WARNING:embedded_test_server.cc(193)] Request not handled. Returning 404: /favicon.ico c:\b\build\slave\drm-cr\build\src\chrome\browser\extensions\extension_bindings_apitest.cc(257): error: Value of: page_success Actual: false Expected: true. |
