chrome.runtime: all functions missing in extension iframe loaded in extension popup
Reported by
tabf...@zoho.com,
Sep 28 2017
|
||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: I am building a Chrome extension (https://chrome.google.com/webstore/detail/hbajjpcdbninabigakflkhiogmmjaakm) and would like to use an iframe in my popup.* Popup /src/view/index.html includes <iframe id="tree-iframe" src="tree.html"></iframe> Iframed file /src/view/tree.html references chrome.runtime APIs. The manifest is, in part: { ... "offline_enabled": true, "manifest_version": 2, "minimum_chrome_version": "54", ... "background": { "scripts": [ "src/common/common.js", "src/bg/background.js" ], "persistent": true }, "options_page": "src/options_custom/index.html", ... "permissions": [ "chrome://favicon/", "tabs", "storage", "unlimitedStorage" ], "web_accessible_resources": [ "src/view/index.html", "src/view/tree.html", "assets/*" ] } * Yes, that is odd, but I can't make CSS do what I want. What is the expected behavior? At least chrome.runtime.connect should be accessible in iframed tree.html. I gather from https://stackoverflow.com/a/26560893/2877364 that iframed pages have permissions similar to those of content scripts. https://developer.chrome.com/extensions/runtime says that chrome.runtime.connect is available to content scripts. What went wrong? In the developer console, chrome.runtime has no functions: > chrome.runtime {PlatformOs: {…}, PlatformArch: {…}, PlatformNaclArch: {…}, RequestUpdateCheckStatus: {…}, OnInstalledReason: {…}, …} OnInstalledReason:{INSTALL: "install", UPDATE: "update", CHROME_UPDATE: "chrome_update", SHARED_MODULE_UPDATE: "shared_module_update"} OnRestartRequiredReason:{APP_UPDATE: "app_update", OS_UPDATE: "os_update", PERIODIC: "periodic"} PlatformArch:{ARM: "arm", X86_32: "x86-32", X86_64: "x86-64"} PlatformNaclArch:{ARM: "arm", X86_32: "x86-32", X86_64: "x86-64"} PlatformOs:{MAC: "mac", WIN: "win", ANDROID: "android", CROS: "cros", LINUX: "linux", …} RequestUpdateCheckStatus:{THROTTLED: "throttled", NO_UPDATE: "no_update", UPDATE_AVAILABLE: "update_available"} __proto__:Object By contrast, in the top-level context, all the events and functions are part of chrome.runtime. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: 6.3 Flash Version: I also tried adding my unpacked extension's ID to externally_connectable in the manifest but saw no change. Ideally, I would be able to whitelist /src/view/tree.html so that it could access all the Chrome APIs just like /src/view/index.html does, even from within the iframe. However, it seems to me more likely that the chrome.runtime.connect missing is a bug, and a fix would be very helpful. (Would you be willing to accept a feature request for such a whitelist?) Let me know if you'd like me to try anything specific. I can use postMessage to send messages back and forth, but I would like to be able to use runtime.connect since I will have a long-running connection. I am not sure if custom CSPs and the manifest sandbox: {} tag would be helpful; that is beyond my scope of experience. I did look at the following, but didn't find an answer: https://blog.chromium.org/2017/05/improving-extension-security-with-out.html Issue 267578 Issue 326250 Issue 432875 Issue 124989 Issue 107538 https://stackoverflow.com/q/21720602/2877364 https://stackoverflow.com/q/30813861/2877364 Thank you!
,
Sep 28 2017
Better repro instructions: 1. Clone https://github.com/cxw42/TabFern.git 2. Check out branch 769823 (creative, right?) 3. Load it as an unpacked extension. When it loads, the popup will appear. 4. Inspect the popup. 5. In the "Top" / Extension context, eval chrome.runtime. You will see what you expect. 6. Change the context to tree-iframe (tree.html) / Extension using the dropdown just above the console. 7. Eval chrome.runtime again. When I do this, I get only what I quoted in comment #0.
,
Sep 28 2017
I can repro with your extension, but the simplified test extension attached here doesn't have any problem with chrome.runtime.connect in an iframe. Can you make a similarly reduced test case that reproduces the bug? Also, FYI, iframe has full permissions due it having the extension's URL.origin i.e. chrome-extension://*id*
,
Sep 28 2017
Reporter, the bug isn't in Chrome, but in your code in src/view/main.js which incorrectly shims chrome API thus breaking it.
,
Sep 29 2017
woxxom, thanks very much for the testcase! The trigger was in my code, but nothing in the shimming. Updated testcase in the repo, at tag 769823-5 (commit 4d60457) - https://github.com/cxw42/TabFern/tree/769823-5/ . In src/view/main.js, accessing window.frames[0] is the trigger. Either of the following lines will cause failure: let W = window.frames[0]; void window.frames[0]; The `void` particularly astonishes me. Reading is enough to change the contents of the chrome object! Any thoughts? Chris
,
Sep 29 2017
I backported from Comment 5 into the reduced testcase from Comment 3 - see attached, also in https://github.com/cxw42/TabFern/tree/769823-6/woxxom . In test.js, uncomment the `void` line for failure; leave it commented for success.
,
Sep 29 2017
It occurred to me I should check --- access is fine after onload, but problematic before then. https://github.com/cxw42/TabFern/blob/769823-7/woxxom/test.js ; also attached. I don't see anything on https://developer.mozilla.org/en-US/docs/Web/API/Window/frames or from a bit of Google searching that suggests window.frames should have side-effects before onload. However, I might just be missing something obvious!
,
Oct 6 2017
Checked this issue on reported version 61.0.3163.100 on Windows 10 with the below mentioned steps and same is observed on M50-50.0.2624.0.: 1. Downloaded and installed the attached 769823-7.zip file. 2. In the pop-up, opened console of devtools 3. Can't find the tree-iframe (tree.html) / Extension in the Top dropdown 4. Console is seen blank in "Top" / Extension context. @Reporter: Could you please find the attached screencast and let us know if we missed any steps from our end. Thanks!
,
Oct 6 2017
kebalaji, thanks for testing! I am sorry for the confusion. The names in comment 2 were from my original code, but since comment 5 I have been using names based woxxom's test case in comment 3.
Update attached. This one fails by default, and logs output to the developer console. So, new steps to repro:
1. Load the attached as an unpacked extension
2. Inspect the popup.
3. Open the Console in the Developer Tools window.
You will see that the "In iframe.js" line is missing `"onStartup":{}` and all the other event handlers that should be in chrome.runtime. You will also see that the two "In test.js" lines include all those. I have attached a marked-up screenshot.
What I expect to see is the same output on all three lines in the console. What I actually see is different output for the iframe.js line. This is triggered by `void window.frames[0];` on 3 of test.js --- comment out that line and refresh the popup, and all three lines match (the expected result).
I disabled all extensions before testing this. I also tried it in a profile with no other extensions loaded at all. Therefore, I do not think it is a problem in code outside of Chrome. If accessing window.frames before onload is forbidden, that should at least be clearly documented in the chrome.runtime docs, or produce a warning on the console :) .
Let me know what you get with the attached. Much appreciated!
,
Oct 6 2017
Thank you for providing more feedback. Adding requester "kebalaji@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 19 2017
woxxom, kebalaji, any thoughts on the c#9 version? I just tried it, and the problem still exists with: Google Chrome 62.0.3202.62 (Official Build) (32-bit) (cohort: 62_62_win) Revision 9da914b118cb0d10d715ccc4ad20575a0305a304-refs/branch-heads/3202@{#700} OS Windows JavaScript V8 6.2.414.32 Flash 27.0.0.170 C:\Users\chrisw\AppData\Local\Google\Chrome\User Data\PepperFlash\27.0.0.170\pepflashplayer.dll Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --disable-smooth-scrolling --top-chrome-md=material --disable-features=MaterialDesignExtensions --flag-switches-end OS is Win8.1 Enterprise. Thanks!
,
Oct 24 2017
Able to reproduce on latest stable 62.0.3202.62 and on latest canary 64.0.3247.0 with the mentioned steps on Ubuntu 14.04, windows 10 and Mac 10.12.6 and same thing is working fine on 50.0.2624.0 Bisect Information: ===================== Good build: 53.0.2753.0(396745) Bad Build : 53.0.2754.0(397000) Unable to provide the bisect as getting all good builds even after increasing the bad range. Hence, assigning it manually and untriaging the issue. Change Log URL: https://chromium.googlesource.com/chromium/src/+log/53.0.2753.0..53.0.2754.0?pretty=fuller&n=10000 Suspecting https://chromium.googlesource.com/chromium/src/+/af6f5247c144b187499b231d13e326add0963089 from above CL @lukasza: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks!
,
Oct 24 2017
The change pointed out in #c12 is a test-only change. This change cannot possibly have an effect on the product.
,
Oct 24 2017
Devlin, could you help triage this bug?
,
Oct 25 2017
Kebalaji, thanks! I am totally ignorant, so feel free to disregard, but what about 0e8dc209f5e4a6140e43551de0e036324c68a383? It's an accessor, not a mutator, so I could imagine it being implicated in the |void window.frames[0]| case. Anyway, I appreciate your work on this!
,
Dec 1 2017
|
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Sep 28 2017