The real reason behind not allowing content scripts to modify chrome: URLs isn't really security, but rather compatibility. Once we allow people to inject content scripts into those pages, then the structure of those pages (DOM, CSS, even JS) essentially become API that we have to find a way to support across versions in order to avoid breaking extensions across Chrome version changes.
In addition to giving the ability to completely replace chrome:// pages, we'd like to provide a few other options in the future which we think should help minimize the need to inject content scripts into chrome:// pages: - Allowing some way to add global hooks to keyboard accelerators and mouse gestures, without requiring content scripts to be injected. - Exposing the features of the new tab page as extension APIs so that it's possible to build a fully-functional replacement. - A modularized gadget API to the new tab page that we could support moving forward independent of changes to the new tab page's layout, etc. No timeline for any of these changes, but they're things that we're considering. Of the three, probably the keyboard and mouse events are the most important. Erik On Sun, Nov 8, 2009 at 10:27 PM, PhistucK <phist...@gmail.com> wrote: > Chrome:// pages have a lot of power in them and executing unsafe stuff on > them may affect Chrome in a destructive way. Other than that, maybe they > want to keep the core features clean, so the user will not think it is > something that "everyone has". > > There is a feature in the extension system, however, that allows you to > override Chrome pages (currently it only supports the new tab page). > http://code.google.com/chrome/extensions/ntp.html (the URL will change > soon to http://code.google.com/chrome/extensions/override.html) has the > syntax. > > Earlier, this being possible was a bug. > <http://code.google.com/chrome/extensions/ntp.html> > ☆PhistucK > > > > On Sun, Nov 8, 2009 at 11:34, Phil Crosby <phil.cro...@gmail.com> wrote: > >> >> Setting chrome://*/* in the content script "matches" section of the >> manifest results in the error: >> >> Invalid value for "content_scripts[0].matches[0]". >> >> Is there another channel by which I can inject code on chrome:// >> pages? >> >> This is the use case: the extension I'm developing provides tab and >> page navigation keyboard shortcuts, and its content script runs on all >> webpages. However, it does not run on chrome:// pages because of the >> above restriction. If you are using my extension to switch tabs via >> the keyboard, once you switch to Chrome's New Tab page, your shortcuts >> will cease to work. >> >> According to this bug, it seems like content scripts may have been >> allowed to execute on chrome:// pages at one point in time: >> http://code.google.com/p/chromium/issues/detail?id=12410 >> >> If anyone has more details behind the rationale for restricting access >> to chrome:// pages, that would be very informative. If this is not >> possible today, I'd be happy to file an improvement ticket for it. >> >> >> > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "Chromium-extensions" group. > To post to this group, send email to chromium-extensions@googlegroups.com > To unsubscribe from this group, send email to > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://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 chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=.
