Content script isn't running in iframe within another extension's page
Reported by
cool...@gmail.com,
Mar 30 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Steps to reproduce the problem: Suppose that 2 extensions are installed in Google Chrome. ------------- 1st extension runs content.js on w3.org: manifest.json: "content_scripts": [{ "matches": [ "https://www.w3.org/*" ], "all_frames": true, "js": [ "content.js" ] }] content.js: alert('content'); ------------- 2nd extension has page.html, which loads w3.org into iframe: manifest.json: "web_accessible_resources": ["page.html"] page.html: <!DOCTYPE html> <iframe src="https://www.w3.org/"></iframe> ------------- Now enter in address bar chrome-extension://2nd-extension-id/page.html. You will see w3.com, but content.js was not running (no alert() window). I do not see errors in console. What is the expected behavior? content.js must be running in iframe (alert() window must be shown). What went wrong? Content script isn't running in iframe within another extension's page. WebStore page: Did this work before? N/A Chrome version: 49.0.2623.110 m (64-bit) Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0
,
Mar 30 2016
We deliberately don't do this for security reasons. Only the owning extension is allowed to run scripts on its pages or subframes. Though this could change with OOPI, since the risk is largely mitigated then.
,
Mar 30 2016
Right-- there's a chance you could relax the restriction once the web iframes run in a different process than the extension (via --isolate-extensions). See https://www.chromium.org/developers/design-documents/oop-iframes.
,
Mar 30 2016
I hope this bug will be fixed after release of the OOPI.
,
Mar 30 2016
This doesn't need full out-of-process iframes support. It can be supported once we ship --isolate-extensions enabled by default.
,
Mar 30 2016
Nasko: I'm not sure the distinction you're making, since we do need out-of-process iframes for this (at least enough to ship --isolate-extensions, as we've both mentioned). Agreed that we don't need full Site Isolation.
,
Mar 30 2016
Indeed I failed to communicate properly. I meant that we need Isolate Extensions support, not full Site Isolation.
,
Mar 31 2016
Side note, neither alert nor console.log seems to have any apparent effect when --isolate-extensions is enabled. Here is a test case that inserts a marker in the page. You can use it to see whether the content script did really. 1. Download and exta-and-b.zip (this contains two extensions, in directories "exta" and "extb"). 2. Start Chrome with both extensions enabled and OOPIF for extensions (I also tried --site-per-process): chromium --load-extension=exta,extb --isolate-extensions 3. Click on the extension button of extension B to open a page with example.com in a frame. 4. Look at the frame and check whether you see "Extension A ran" and/or "Extension B ran" in the frame, and whether there are console messages and/or dialogs. Actual (in Chrome 51.0.2696.0): - Only "Extension B ran" is shown. - There are no messages in the console. - There are no alert dialogs. Expected: - I should see "Extension B ran" in the page. - I should see "Extension B ran" in the console. - I should get an alert dialog showing "b". - And maybe also the above, but then for extension A (that is this bug). Site isolation folks: Were you aware of these bugs (i.e. console messages not appearing and dialogs not showing up)? If not, please create new tickets and reference this test case.
,
Mar 31 2016
@8 Sanity check - you looked at the console for the subframe, right, not just the top frame? Re A not running, right now we have a specific check that the top-level frame isn't an extension page (separate from process checks), so this is expected behavior. When we launch Isolate Extensions, we can re-evaluate this decision, but (unlike the blessed vs unblessed context) this won't just automagically work.
,
Mar 31 2016
#9 Confirmed that the message does show up in the frame's console (I expected it to be aggregated with the main frame's console, just like the non-OOPIF case). The alert dialog doesn't appear though.
,
Mar 31 2016
Yes, alerts are a known problem and tracked in issue 453893 . |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by cool...@gmail.com
, Mar 30 2016