Skip to content
This repository has been archived by the owner on May 26, 2024. It is now read-only.

Clarify discrepancy between permission for "tabs" between Browser Extension and Chrome APIs #59

Open
dellagustin opened this issue Jan 26, 2020 · 1 comment

Comments

@dellagustin
Copy link

Hello,

The current version of the Chrome APIs state the following:

You can use most chrome.tabs methods and events without declaring any permissions in the extension's manifest file. However, if you require access to the url, pendingUrl, title, or favIconUrl properties of tabs.Tab, you must declare the "tabs" permission in the manifest, as shown below:

Meanwhile, Browser Extensions spec states:

The "tabs" permission is required to use this object.

Is the current status of the spec intended as final, or do you envision to align with the current state for Chrome APIs?

Regarding my use case

I do have a use case that is not supported by either specifications.

In my extension I use the tabs object to query for open tabs of my own extensions:

window.openPodStation = function(hash) {
	chrome.tabs.query({url: `chrome-extension://${chrome.runtime.id}/podstation.html`}, function(tabs) {
		if(tabs.length) {
			chrome.tabs.update(tabs[0].id, {active: true});
			chrome.windows.update(tabs[0].windowId, {focused: true});

			if(hash) {
				chrome.tabs.update(tabs[0].id, {url: '/podstation.html' + '#' + hash });
			}
		}
		else {
			window.open('/podstation.html' + ( hash ? '#' + hash : ''));
		}
	});
}

The intended behavior is to avoid creating additional tabs for showing the extension page, but bring one of the existing tabs into focus.

I was hoping that no explicit permission would be necessary for this case, as I am only accessing and modifying tabs that show pages from my extension.

References:

@frivoal
Copy link
Member

frivoal commented Jan 28, 2020

Thank you for reporting this issue. Unfortunately, due to a chronic lack of participation, this group has become dormant and work isn't actively being done. This unfortunately means you are unlikely to receive an answer to this issue in the near future. As far as I know, nobody is opposed to this work, so it may eventually resume, but at the moment the group is not active.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants