Charlie, does this sound like something that is reasonable to do?

I'm not sure exactly what's being proposed.  It's not ok for extensions to load chrome:// URLs in general, but there may be a way to have a sufficiently narrow exception.

That said, I don't know enough about what we store in chrome://resources to say whether we could grant an exception specifically to component extensions (or whitelisted extensions).

Devlin, do you know whether there's a better way for extensions to load content stored in Chrome like this?

Justin/Tom, do you know if there's precedent for exposing certain Chrome resources outside of WebUI pages?

Of course, one risk outside security is that the extension and Chrome itself will update at different intervals.  That means you could end up with incompatible versions on either side.  Have you considered how to address that aspect?

We already have one exception for chrome://favicons, and that's caused us endless headaches because it means we can't totally lock down the chrome:// scheme to extensions.  Awhile back, I tried to push for something like chrome-static://, which had static resources like this in a way that extensions could access, but was shot down because we didn't want to introduce a new scheme.  I'd still rather that than introduce new security exceptions for the chrome:// scheme, though.

Yes, sounds like you're referring to  issue 226927 .  Those exceptions are indeed a huge headache.

I'm not familiar with the eng review reasoning cited on that bug for not adding chrome-static:// as a scheme, and it sounds like that would need to be resolved to have a way for chrome:// and extensions to share the same copy of Polymer.  Thus, I'm not a good owner for this bug.

I also don't know how you're planning to solve versioning, per comment 3.

Versioning wise the Media Router extension has a release process that closely follows Chrome where each version of the extension is tied to a Chrome milestone so it probably wouldn't be an issue for Media Router, but other extensions would have to come up with a way of handling it.

That said, the url has a v1_0 in (chrome://resources/polymer/v1_0/polymer/polymer.html)

Are you saying that even if we had v1_0 as the referenced version it could still be updated with a breaking change?

@6 we have updated the v1_0 repo of polymer with breaking changes.  Often, these are changes that the polymer team didn't expect to be breaking, but actually were (e.g. changing css values that causes stuff to look funny or render improperly).

Additionally, I don't think we want to ship multiple versions of polymer, so if chrome updated to v2_0 and the extension referenced v1_0, there wouldn't be a corresponding file - so it's still a breaking change.

That said, I'm still not opposed to this general idea, but it is something extension authors would have to think about carefully.

 Issue 280234  has been merged into this issue.

We don't have a need to access Polymer in an extensions context any more.  If no one else as asked for this, seems like we should just close it out.

There was some other interest in this aside from polymer and I think it would be generally useful so we should leave it open (but agree that it may no longer be relevant for media router).