Open Bug 1374255 Opened 8 years ago Updated 8 months ago

activeTab of permissions is not valid for tabs.executeScript in sidebar_action

Categories

(WebExtensions :: Frontend, defect, P3)

55 Branch
defect

Tracking

(firefox57 wontfix)

UNCONFIRMED
Tracking Status
firefox57 --- wontfix

People

(Reporter: sin, Unassigned)

Details

(Keywords: testcase, Whiteboard: [sidebar][triaged])

Attachments

(2 files)

Attached file TestExecuteScript.xpi
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170615070049 Steps to reproduce: "activeTab" is set in "permissions" in manifest.json. Can not execute tabs.executeScript() for the active tab in sidebar_action. "Error: Missing host permission for the tab" is output to the browser console. But it is succeeded in non-sidebar_action. Steps to reproduce: 1. Install TestExecuteScript.xpi. Activate mozilla.org page in the active tab. 2. Click "Execute Script" button in the sidebar. > Error Click "Execute Script by IFrame" button in iframe in the sidebar. > Error 3. Click toolbar button and Click "Execute Script" button in the popup of browser_action. > Success Click toolbar button and Click "Execute Script by IFrame" button in iframe in popup of browser_action. > Success 4. Click "Execute Script" button in the sidebar. > Success Click "Execute Script by IFrame" button in iframe in the sidebar. > Success Version: 56.0a1, Build ID: 20170618030207, OS: Windows_NT 10.0 Version: 55.0b2, Build ID: 20170615070049, OS: Windows_NT 10.0 Actual results: When tabs.executeScript() is executed in sidebar_action at first, Error. When tabs.executeScript() is executed in browser_action at first, Success. After tabs.executeScript() is executed in non-sidebar_action, Execution tabs.executeScript() in sidebar_action succeeds. Expected results: If "activeTab" is set in "permissions", when tabs.executeScript() is executed in sidebar_action at first, Success.
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
Has STR: --- → yes
Keywords: testcase
Priority: -- → P3
Whiteboard: [sidebar][triaged]
Product: Toolkit → WebExtensions
Assignee: nobody → onlinericha19

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: onlinericha19 → nobody
Severity: normal → S3

Comment 0 states that the expected behavior is, "If 'activeTab' is set in 'permissions', when tabs.executeScript() is executed in sidebar_action at first, Success." I understand why an extension developers would want (I do too), but at the moment I don't think browsers should grant the activeTab permission in this case.

The original issue report appears to be conflating interactions with DOM content of extensions pages and how activeTab is granted. The activetTab permission is not granted when the user clicks the "Execute Script" button in step 3. Rather, activeTab is granted when the user clicks the toolbar button in step 3. When the user later clicks the "Execute Script" button a moment later in that step, it has already been given the permissions necessary for the tabs.executeScript() call to succeed. This may seem like an inconsequential difference, but it's key to understanding why the button in the popup currently works but the button in the sidebar does not; in the latter case the browser does not have a clear signal that the user intended to give the extension access to the page.

IMO user interactions with a sidebar content are not a strong signal that the user wants to run the extension on the current page. The user may be interacting with a sidebar page for a variety of reasons that have nothing to do with exposing sensitive information about the page to the extension or running the extension on the current page. For example, imagine an extension that shows the user's to do list in the sidebar. The user may be might interact with the sidebar to add items to a grocery list or to mark an existing item as complete.

I would be more comfortable with granting activeTab if the sidebar interactions that could grant it were heavily limited. For example, say we only granted the permission for trusted click events (a concept not supported in web APIs) on button elements in the sidebar. I still worry that the incidence of spurious grants would be too high, but I'd defer to a security expert here.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: