Thinking about this more, this might be WAI since it only fails on chrome:// urls (in the CL, it sounded like it was all urls).  We don't expose the url if the extension doesn't have access to the page, and no extensions have access to the chrome:// pages.  Requesting the "tabs" permission gives you access to see all the user's browsing, including sites you can't inject on.  From an extension standpoint, if you have all_urls, you can pretty much assume that anything you don't get the url for is chrome (or otherwise protected) url.

Almost more interesting is that it *works* with activeTab - that seems like a bug to me.

+asargent for his thoughts.

> Almost more interesting is that it *works* with activeTab - that seems like a bug to me.

Wait, is it the case that adding the activeTab permission lets you see the url of tabs other than the active one? If so that's definitely a bug. If it just grants you tabs permission to see the url of whatever tab is focused when the browser action was clicked, then that sounds like WorkingAsIntended(tm). 

We have a few pieces of logic here.

If the extension has "tabs" permission, we can always show the tab urls - that's what the permission's for.
If the extension has access to inject scripts into Tab, then we can return the url of Tab (because the extension could just inject a script to message the location.href).
If the extension has activeTab permission and is invoked on Tab, then it can inject scripts there (and thus we can return the url).

Now, what's happening is that without activeTab and without the tabs permission but with all urls, we return the url for 99% of tabs - because the extension can inject everywhere.  This is WAI.  On chrome pages, we don't return the url, because the extension *can't* inject there.  IMO, also WAI.  But with activeTab (and still without tabs permission), the extension *can* get the url of chrome:// pages, even though it cannot inject there.  To me, that last part seems like a bug, since our logic is supposed to be "if the extension can inject here, return the url because it could figure it out anyway" - but that's not the case for a chrome:// page.

Quoting from https://developer.chrome.com/extensions/activeTab#what-activeTab-allows :

While the activeTab permission is enabled for a tab, an extension can:

* Call tabs.executeScript or tabs.insertCSS on that tab.
* Get the URL, title, and favicon for that tab via an API that returns a tabs.Tab object (essentially, activeTab grants the tabs permission temporarily).

-----

That last part seems to me like this is working as specified. 

Right, but that's explicitly disallowed on chrome pages.  e.g. even with activeTab we don't (and definitely shouldn't!) let an extension call executeScript on chrome://settings or chrome://extensions.