Possible Bug/Unexpected Behavior with "activetab" Permission and Side Panel View

[Robert James Gabriel]

Hello everyone,

I would like to bring to your attention a potential bug or unexpected behavior that I have encountered regarding the "activetab" permission when using the side panel view in a Chrome extension. I am seeking insights from the community to better understand if this behavior is expected or if it should be considered a bug.

Issue Description:
When utilizing the "activetab" permission in conjunction with the side panel view, it appears that the permission does not provide temporary access as expected. Specifically, I have encountered an issue when attempting to use the `captureVisibleTab` API to capture a screenshot of the active page and initiate a download.

In the background script, when the extension is using the pop-up menu, the `captureVisibleTab` API functions flawlessly. However, upon switching to the side panel view, an error is encountered: "Unchecked runtime.lastError: Either the '<all_urls>' or 'activeTab' permission is required."

Objective:
My objective is to avoid adding the "all_urls" permission, as doing so may trigger a new warning for the extension. I would like to determine whether the observed behavior is expected or if it should be considered a bug with the "activetab" permission in conjunction with the side panel API and Manifest V3.

Clarification:
I kindly request the assistance of fellow developers who have experience with Chrome extensions and the "activetab" permission to share their insights. Specifically, I would like to know if this behavior is by design or if it should be considered a bug that needs to be addressed. Any suggestions or workarounds to achieve the desired functionality within the side panel view without requiring the "all_urls" permission would be greatly appreciated.

Thank you for your time and valuable input.

Thank you
Robert James Gabriel

---

Please feel free to customize the form post according to your specific requirements and include any additional details that might be relevant to your situation. Good luck with resolving the issue!

[Jackie Han]

For chrome.action.onClicked.addListener, "activeTab" permission works.

But the side panel is similar to opening the popup page, so "activeTab" permission doesn't work.

So this behavior fits the current design of "activeTab".

Maybe we can request a feature that binds a user gesture in the popup/sidepanel page with "activeTab'' permission.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/537e1a98-be9e-44c6-be90-dab4b170d17en%40chromium.org.

[wOxxOm]

Since the UX workflow of the side panel is the same as that of the action popup, this is clearly a bug, either in the design of the API or in its implementation. The workaround might be to add a clickable button in the panel and use captureVisibleTab inside.

[wOxxOm]

> But the side panel is similar to opening the popup page, so "activeTab" permission doesn't work.

> So this behavior fits the current design of "activeTab".

No, the action popup actually works with "activeTab" without the need for an explicit click listener. The same must apply to side panel, but since it doesn't per the OP's report, it's clearly a bug.

[Jackie Han]

Currently, I don’t use the onClicked event listerner. Instead the user clicks a button in the pop up menu, that sends to the background script that captures the screenshot and then I download it.

Thank you both for your replies. I just did two experiments.

Experiment-1: In a click button listener in popup/sidepanel page, sendMessage to background. In background message listener, captureVisibleTab

1) In popup page mode, it works.

2) In side panel mode, it doesn't work.

Experiment-2: run captureVisibleTab when popup/sidepanel page startup

1. In popup page mode (in popup.js), it works.

2. In side panel mode (in sidepanel.js), it doesn't work.

The official doc doesn't explain whether it works for above cases. But side panel mode should behave the same with popup mode, thus this should be a bug.

On Fri, Jun 9, 2023 at 4:10 AM Robert James Gabriel <gti...@gmail.com> wrote:

Hey Jackie,

Thank you for the reply, yeah I think it might be but I will follow up with video showing the issue too.

Currently, I don’t use the onClicked event listerner. Instead the user clicks a button in the pop up menu, that sends to the background script that captures the screenshot and then I download it.

If I change nothing else but to default to the side panel view in the manifest this doesn’t work and gets the error as described.

Thank you

Robert James Gabriel

On Jun 8, 2023, at 15:03, Jackie Han <han.g...@gmail.com> wrote:



[Jackie Han]

Missing the link https://developer.chrome.com/docs/extensions/mv3/manifest/activeTab/#invoking-activeTab

[Jackie Han]

Experiment-3: In a click button listener in popup/sidepanel page, run captureVisibleTab directly

1) In popup page mode, it works.
2) In side panel mode, it doesn't work.

[Jackie Han]

I reported this bug at https://crbug.com/1453437 with details sample code

[Oliver Dunk]

Thanks all for flagging this!

We did briefly consider this when building the API and decided against adding activeTab permissions, because the Side Panel can stay open across tabs and suddenly losing permissions while the panel is still open could be confusing. Definitely open to feedback though, so appreciate you opening the bug Jackie. I think inconsistency with the popup is definitely the thing that makes me most unsure about if we went the right way or not.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAAgdh1%2B6LP7PUufe0hRbAAHBc1%3Dr9YA%2BPMQ1fjk9r5vx7SJLkA%40mail.gmail.com.

[wOxxOm]

> We did briefly consider this when building the API and decided against adding activeTab permissions, because the Side Panel can stay open across tabs and suddenly losing permissions while the panel is still open could be confusing

If the user just opened the side panel or explicitly clicked inside, it is physically a user gesture, so not retaining is unexpected/wrong, clearly a bug. Furthermore, the "user gesture" flag is retained for about 1 second in the web platform as far as I know, so there should be no problem of "suddenly losing permissions" as it is the expected behavior by now. If the extension platform doesn't behave like this and instead retains the gesture indefinitely in the popup then it'd be a bug as well.

[Robert James Gabriel]

> If the user just opened the side panel or explicitly clicked inside, it is physically a user gesture, so not retaining is unexpected/wrong, clearly a bug. Furthermore, the "user gesture" flag is retained for about 1 second in the web platform as far as I know, so there should be no problem of "suddenly losing permissions" as it is the expected behavior by now. If the extension platform doesn't behave like this and instead retains the gesture indefinitely in the popup then it'd be a bug as well.

I 100% agree with this. The user gesture part would be the perfect soultion.

I would be happy to right all the use case for it :D 

[Jackie Han]

because the Side Panel can stay open across tabs and suddenly losing permissions while the panel is still open could be confusing.

 

I think the side panel should support "activeTab" permission. From a security point of view, "user gesture" grants a temporary permission to do something (call some api) in a very short time. After that, it needs "user gesture" again (e.g. click a button in side panel again). "activeTab" should bind to a Tab+Origin, when switching to other tab the temporary permission could be revoked at once. With this security model, it should be safe to use in the side panel.

[Robert James Gabriel]

This is fixed in the latest version.

wooo

[styleb...@gmail.com]

Ho Robert,

I could not find the fix, could you please share the link? 

*updated to the latest Chrome version(118.0.5993) and the behavior is still the same - cannot not access activeTab from sidePanel

- Sergii

четвер, 24 серпня 2023 р. о 20:37:03 UTC+3 Robert James Gabriel пише:

[Cyberj]

I don't think the issue was fixed. I'm seeing the same error when trying trying something with activeTab from the side panel. I'm using the latest Chrome version 119.0.6045.159.

I also tried for example  using `captureVisibleTab` API  in a service worker, sent by a user click in the side panel and I still get the same error: "Either the '<all_urls>' or 'activeTab' permission is required".

I'm also passing the activeTab window id. 

As mentioned, it works if I try it from a popup. Does anyone have any update on this? Thanks!

[Cyberj]

One more note, it works for example if i open and close the popup, then try from side panel. But not directly when trying from side panel, which I found weird. If you restart your Chrome extension, do not open the popup, and try from side panel, the error will show. 

[wOxxOm]

> it works for example if i open and close the popup, then try from side panel. But not directly when trying from side panel, which I found weird.

This is not a bug. When you open the popup it auto-grants access to the active tab's URL origin per the "activeTab" permission's documented rules, and this auto-granted permission lasts as long as this tab contains the original page (or a same-origin page, IIRC) and the permission is granted to the entire extension, including the side panel.

I vaguely remember some public comments from a Chrome team developer (maybe rdevlin's somewhere in https://github.com/w3c/webextensions) that they intentionally decided to keep the current behavior of the sidepanel (i.e. not to grant activeTab) because, unlike the popup, it's not as evident to the user that they "invoke" the extension, probably because it is shown persistently and hence there's no modal activation. There might be a solution that addresses their concerns and provides a self-evident and simple UX, so if you have one you can suggest it in https://crbug.com/1453437 or in a new report.