+1 for granting iframed extension pages access to the chrome.extension API. Here's my use-case:
My extension requires frequent user-input, so I need to pop a small form in response to a key-event (I've seen other discussions requesting this sort of behavior as well). Given the various security and usability restrictions imposed on chrome extensions, I've struggled for a week and still haven't found a good way to do this. I've tried putting the form: * in popups for browser- and page-actions (these require the user to click on an icon; not viable for my use-case) * in a toolstrip (I understand these are deprecated, and also wasn't able to transfer keyboard focus to the form) * in a wholly separate window, via window.open() (terrible user experience, cumbersome to manage the connection with the correct tab) * on the page embedded in an iframe (totally unworkable -- impossible to connect to the extension and/or the enclosing window) * in a div added to the page itself (my current workaround; unsatisfactory because it destroys the "selection" on the page when it takes focus, and also because it's subject to CSS conflicts) I believe the ability to display a user interface in response to a keyboard action is a fundamental requirement for power users. Do you have a suggestion for how to achieve this in an extension? (Also, BTW, I'm having difficulty understanding the security risks implied by giving extension-provided pages in iframes access to extension ports: perhaps it's related to the implementation, but this seems intuitively LESS dangerous than giving the same access to embedded content-scripts..?) Thanks, -joshng On Nov 30, 11:35 am, Adam Barth <[email protected]> wrote: > One thing we've considered is having extension declare some of their > URLs "public," which would let web content navigate to or iframe those > URLs. > > There's some security benefit in not letting arbitrary render > processes access the chrome.* APIs. Another possibility is to have a > "content page" that is like a content script in that it gets a > message-passing channel back to the main extension process, but has a > URL and HTML. (We'd have to think about what kind of URL it would > have.) > > Adam > > > > On Mon, Nov 30, 2009 at 8:34 AM, Aaron Boodman <[email protected]> wrote: > > +abarth, security guru > > > This is by design. I think it is something we may eventually > > reconsider, but we started this way to be conservative. > > > - a > > > On Mon, Nov 30, 2009 at 1:17 AM, Arrix <[email protected]> wrote: > >> Hello, > > >> I'm trying to embed an extension page (chrome-extension://<id>/ > >> somepage.html) as an iframe inside the content page. It seems that the > >> extension page cannot access any chrome APIs. > >> console.log(chrome.extension) //=> undefined > > >> The extension page works well when loaded in a tab. > >> Is this a designed behavior or an implementation limitation? > > >> Anyhow, is this usage (extension page in iframe of content pages) > >> discouraged for some reason? > >> The use case is to show a context popup in a webpage. iframe is used > >> to avoid css conflicts. > > >> Thanks, > >> Arrix > > >> -- > > >> You received this message because you are subscribed to the Google Groups > >> "Chromium-extensions" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group > >> athttp://groups.google.com/group/chromium-extensions?hl=en. -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
