captureVisibleTab in new tab overriden by "chrome_url_overrides"

56 views
Skip to first unread message

Robbi

unread,
May 21, 2022, 6:53:49 PMMay 21
to Chromium Extensions
I was wondering if chrome.tabs. captureVisibleTab works in a  new tab overriden by "chrome_url_overrides".
It'd seem not.
Is there a workaround or some web api that I could use as an alternative?
I would like to create a rudimentary magnifying glass that is activated by clicking on an image (not browser action).
Do I have any chance?
Thanks

wOxxOm

unread,
May 22, 2022, 4:54:54 AMMay 22
to Chromium Extensions, Robbi
If it doesn't work with "permissions": ["<all_urls>"] then it's a bug, which you can report on https://crbug.com. Meanwhile you can try opening a new window that will invoke the API, or add an iframe with a chrome-extension:// URL and call the API there.

Robbi

unread,
May 22, 2022, 6:40:59 AMMay 22
to Chromium Extensions, wOxxOm, Robbi
Hi wOxxOm,
I tried all the workarounds you suggested me, but unfortunately none of them works.
It seems the method fails not only on new tabs but also on all extension pages (chrome://extensions_id/*).
With other normal web pages it works instead.
The error I get when I invoke it when a extension page is selected on target windos is "The 'activeTab' permission is not in effect because this extension has not been in invoked." Note that I add "<all_urls>" permission in manifest file.
At this point, I suspect this method was designed to work only in content scripts.

wOxxOm

unread,
May 22, 2022, 6:43:58 AMMay 22
to Chromium Extensions, Robbi, wOxxOm
Content scripts can't use chrome.tabs API so no, it's definitely a bug. So far the only workaround is to use browser_action, which you don't want though.

Robbi

unread,
May 22, 2022, 7:11:18 AMMay 22
to Chromium Extensions, wOxxOm, Robbi
You're right, content scripts can't use chrome.tabs API.
I wanted to refer to all those extensions in the store that perform the function of magnifier.
I have installed a couple of these.
These are activated on the browserAction and work on all normal web pages except pages whose URL starts with chrome: //.
However, I see no reason to ban this method to extension pages.
It would be advisable to grant use to our own pages without giving <all_urls> permission which in these use cases would also be excessive.
Do you think it is appropriate to open a bug or ask for a new feature?

wOxxOm

unread,
May 22, 2022, 7:17:26 AMMay 22
to Chromium Extensions, Robbi, wOxxOm
Since it worked before https://crrev.com/548891 landed in Chrome 67, it's technically a bug.

hrg...@gmail.com

unread,
May 22, 2022, 10:33:06 AMMay 22
to Chromium Extensions, wOxxOm, Robbi
According to the tabs.captureVisibleTab documentation, "sensitive sites can only be captured with the activeTab permission".
Sensitive sites are "chrome:-scheme pages, other extensions' pages, and data: URLs".

Since the URL of the new tab page is chrome://newtab (whether it's overridden or not), the limitation you are facing is documented.

wOxxOm

unread,
May 22, 2022, 10:36:49 AMMay 22
to Chromium Extensions, hrg...@gmail.com, wOxxOm, Robbi
> the limitation you are facing is documented 

No, the extension has access to its own tab so it definitely should be capable of capturing it even without activeTab.

wOxxOm

unread,
May 22, 2022, 10:44:08 AMMay 22
to Chromium Extensions, wOxxOm, hrg...@gmail.com, Robbi
To elaborate, I guess the bug in Chrome is caused by the fact that the newtab has a chrome://newtab URL internally but the person who implemented https://crrev.com/548891 forgot to add a check for an overridden newtab's effective origin which is the extension's own origin. P.S. as mentioned earlier, a workaround is possible via browser_action.

hrg...@gmail.com

unread,
May 22, 2022, 10:58:39 AMMay 22
to Chromium Extensions, wOxxOm, hrg...@gmail.com, Robbi
That's not clear in the documentation. An overridden chrome:// URL is a special case and the documentation doesn't specify any special behavior for that case. So the current API behavior matches the documentation.

I agree that this should be corrected, but the documentation must be clear about it first.

Message has been deleted
Message has been deleted

Robbi

unread,
May 22, 2022, 11:09:23 AMMay 22
to Chromium Extensions, hrg...@gmail.com, wOxxOm, Robbi
I've been banging my head since this morning.
It would seem that <all_urls> allows you to capture ONLY the ACTIVE tab without necessarily having to click on the browseAction.
I tried via tab.update to divert the focus to another tab and then to take the photo and it works ONLY if the page schema is NOT chrome://
With the activeTab permission, on the other hand, it also works on pages with a chrome:// schema as long as the "activeTab" grant is given to the tab by clicking on the browserAction.
After the tab has acquired that grant, captureVisibleTab can be used through a simple button.
Behavior, in my opinion, very strange.

I develop a small extension for testing purpouse.
Here is the link: LINK

Clicking the browserAction the first time, a page extension opens with same buttons
whereas the following clicks (on browserAction) activate the tabs.captureVisibleTab on current tab.
In manifest file there is already <all_urls> permission.
It can  obviously comment this permission and add "activeTab" to perform all combination tests


wOxxOm

unread,
May 22, 2022, 11:21:42 AMMay 22
to Chromium Extensions, Robbi, hrg...@gmail.com, wOxxOm
It's a bug, simple as that, because the API must work with the activeTab permission even when invoked from an overridden chrome://newtab page as stated in the documentation. I would have reported it myself right away but dozens of the reports I made aren't fixed yet so I'm pessimistic about it.

As for a workaround you can use the extension's icon itself to initiate capturing instead of using a button inside your newtab page. I guess you would need to declare a background script and use chrome.browserAction.onClicked inside.

Reply all
Reply to author
Forward
0 new messages