Closed Bug 1584897 Opened 5 years ago Closed 5 years ago

API to get recently closed tabs requires two permissions "sessions" and "tabs"

Categories

(WebExtensions :: General, defect)

69 Branch
defect
Not set
normal

Tracking

(firefox69 affected, firefox70 affected, firefox71 affected)

RESOLVED INVALID
Tracking Status
firefox69 --- affected
firefox70 --- affected
firefox71 --- affected

People

(Reporter: coder-ant, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Used the webextension API sessions.getRecentlyClosed() to get the recently closed tabs and display the information about those tabs (url and title).

Actual results:

To retrieve the url and title information of the recently closed tabs requires "tabs" permission in addition to "sessions" permission

Expected results:

An extension should be able to retrieve and display the recently closed tabs information using only one permission and should not require "tabs" permission which opens up more access to the extension than required.

Summary: API to get recently requires two permissions "tabs" and "sessions" → API to get recently closed tabs requires two permissions "tabs" and "sessions"
Summary: API to get recently closed tabs requires two permissions "tabs" and "sessions" → API to get recently closed tabs requires two permissions "sessions" and "tabs"
Component: Untriaged → General
Product: Firefox → WebExtensions
Version: 69 Branch → Firefox 69

Hello,

I have managed to reproduce the results on the latest Nightly (71.0a1/20191002033852), Beta (70.0b11/20190930132843) and Release (69.0.1/20190917135527) under Windows 10 Pro 64-bit and MacOS High Sierra 10.13.6.

For this I have employed 3 extensions using the sessions.getRecentlyClosed() API, with both permissions (tabs and sessions), only one permission (sessions) and no permissions, with the following results:

  • tabs + sessions permissions: the url and title of the recently closed tab is displayed
  • only sessions permission: the url and title of the recently closed tab is not displayed
  • no permissions: the undefined error is displayed (due to lacking the necessary permissions in the manifest file)
Status: UNCONFIRMED → NEW
Ever confirmed: true

An extension should be able to retrieve and display the recently closed tabs information using only one permission and should not require "tabs" permission which opens up more access to the extension than required.

the "tabs" permission doesn't "open up more access to the extension", besides being able to access url and title of the tabs,
As the MDN docs (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) mentions:

tabs gives you access to privileged parts of the tabs API: Tab.url, Tab.title, and Tab.faviconUrl. In Firefox, you also need tabs if you want to include url in the queryInfo parameter to tabs.query(). The rest of the tabs API can be used without requesting any permission.

Which means that the "tabs" permission is meant to give to the extension access to the url and title of the tabs, while the tabs API is available even without requesting any additional permission.

And so the behavior described in comment 1 looks the expected one:

  • tabs + sessions permissions: sessions permission gives access to the sessions API, the tabs permission gives to the extension access to url and title of the tabs in the recently closed session

  • session permission without tabs permission: the session API is available and allowed as expected, the url and title of the tabs are omitted because the "tabs" permission is missing (which is also expected, nevertheless the extension can still use the API, e.g. to restore or forget a session without knowing exactly which urls were opened in those tabs)

  • no session permission: the session API is unavailable and so it is undefined.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Version: Firefox 69 → 69 Branch
You need to log in before you can comment on or make changes to this bug.