Running an extension page inside an iframe

[Marcin Simonides]

Hello,

I'm investigating whether it's feasible to run an extension page (chrome-extensions://<id>/some_page.html) within an iframe.

I can easily embed the page but none of the allowed APIs like tabs available. If I load it as a main page (top-level frame) the APIs are available.

As far as I know the code responsible for making a document an extension page is in ExtensionWebContentsObserver which sends the ExtensionMsg_Loaded and ExtensionMsg_ActivateExtension messages to the Dispatcher in the renderer. The ExtensionWebContentsObserver does its work on RenderViewCreated which isn't called for iframes so I have tried handling RenderFrameCreated as well.

Unfortunately at this point I don't see a way to obtain the URL of the iframe at this point (RenderFrameHost::GetSiteInstance returns the SiteInstance for the main page).

My immediate question is: can I obtain the iframe URL in RenderFrameCreated and how?

But before I dig deeper into this, I'd like to also ask:

- Is this approach sane?

- What other problems should I expect along this path? Should I expect that many changes will be required also on the renderer side?

- In content/public/browser/render_frame_host.h one can read a comment: "Temporary until we get rid of RenderViewHost". Does it mean that the RenderViewHost will eventually be removed completely and the extensions code will have to work with RenderFrameHost? In that case, would my work towards running extensions inside iframes be of some use to the Chromium project and potentially worth upstreaming?

I'm doing this for a component extension and an internal page only so I'm not concerned about security issues that would arise if any arbitrary page was allowed to embed extensions pages.

[PhistucK]

I really do not know anything about this, but I reckon that the out of process iFrames work could help you achieve what you want.

Currently, the iFrame would be loaded in the same process and only special processes (extension processes and others) can use these APIs, so an out of process iFrame (once implemented) could be a special process (if the implementation permits), therefore granting access to privileged APIs.

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Nasko Oskov]

On Wed, Jun 11, 2014 at 9:19 AM, PhistucK <phis...@gmail.com> wrote:

I really do not know anything about this, but I reckon that the out of process iFrames work could help you achieve what you want.

Currently, the iFrame would be loaded in the same process and only special processes (extension processes and others) can use these APIs, so an out of process iFrame (once implemented) could be a special process (if the implementation permits), therefore granting access to privileged APIs.

Yes, you are correct that longer term once we are done with out-of-process iframes, this should be doable.

 

On Wed, Jun 11, 2014 at 5:33 PM, Marcin Simonides <msimo...@opera.com> wrote:

Hello,

I'm investigating whether it's feasible to run an extension page (chrome-extensions://<id>/some_page.html) within an iframe.

I can easily embed the page but none of the allowed APIs like tabs available. If I load it as a main page (top-level frame) the APIs are available.

This is due to how the Chrome process model works. Extensions run in processes with extra privileges, which allows them to call extension APIs. Regular web pages don't get those privileges, so you don't get any extension APIs even though you embed extension content. As PhistucK pointed out, once we can run frames in arbitrary processes, it will be technically possible to grant privileges to the content in the extension iframe.

 

As far as I know the code responsible for making a document an extension page is in ExtensionWebContentsObserver which sends the ExtensionMsg_Loaded and ExtensionMsg_ActivateExtension messages to the Dispatcher in the renderer. The ExtensionWebContentsObserver does its work on RenderViewCreated which isn't called for iframes so I have tried handling RenderFrameCreated as well.

Unfortunately at this point I don't see a way to obtain the URL of the iframe at this point (RenderFrameHost::GetSiteInstance returns the SiteInstance for the main page).

My immediate question is: can I obtain the iframe URL in RenderFrameCreated and how?

No, it isn't available right now. It might be added, but I question the need for that since there are separate APIs to monitor navigation of frames.

 

But before I dig deeper into this, I'd like to also ask:

- Is this approach sane?

Prior to out-of-process iframes, it is just not possible. We are working on that though :).

 

- What other problems should I expect along this path? Should I expect that many changes will be required also on the renderer side?

- In content/public/browser/render_frame_host.h one can read a comment: "Temporary until we get rid of RenderViewHost". Does it mean that the RenderViewHost will eventually be removed completely and the extensions code will have to work with RenderFrameHost?

Yes!

 

In that case, would my work towards running extensions inside iframes be of some use to the Chromium project and potentially worth upstreaming?

If you can help move the extensions code away from RenderViewHost and to RenderFrameHost, this will be very very valuable contribution and I'd welcome it wholeheartedly. 

 

I'm doing this for a component extension and an internal page only so I'm not concerned about security issues that would arise if any arbitrary page was allowed to embed extensions pages.

This doesn't make much difference, unless you run the "internal page" in a special process that you give privileges to. Regular web content renderer must not get extension privileges. The proper solution to this, though not immediate, is to let each frame be placed in appropriately permissioned process.