1510215 - tabs.query with activeTab permission does not allow access to tab with URL just downloaded / only returns about:blank with tabs

Status: RESOLVED INVALID

(WebExtensions :: General, defect)

Description

[rugk]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

1. Open https://grobox.de/tmp/briar-add-contacts-remotely-user-test.apk in a new tab. (right-click -> open in new tab)
2. Trigger your extension. (e.g. via action buttons)

This extension has the "activeTab" permission and queries the tab like this:
browser.tabs.query({active: true, currentWindow: true});

To quickly test it, you may also use this (in the console):
browser.tabs.query({active: true, currentWindow: true}).then(console.log);


Actual results:

Actually neither URL nor title are available, so it seems it denies me the permission.

When you now change the permission to "tabs" I get "about:blank", so probably because of that, it denies me access.
Also, obviously, this is still wrong and not the URL I expect. (as a dev and then obviously as a user as the add-on uses/sees that)


Expected results:

As the URL is shown in the address bar, you should also deliver that to the add-on. Everything else is quite unexpected.

The downstream bug of my add-on for this is tracked in https://github.com/rugk/offline-qr-code/issues/146 and you can thus test it live in "Offline Qr Code Generator".

Comment 1

[rugk]

Even more funny, BTW, if the tab is later discarded (also an WebExtension feature) and re-loaded, I actually do have permission to access the URL of about:blank…

Anyway the URL should be different, of course. Or should I open a new issue/ticket for that?

Comment 2

[Rob Wu [:robwu]]

When a download happens, the navigation is not actually committed to the given tab. Therefore "about:blank" is the expected URL of the tab.

Have you tried using the webNavigation API/events to identify this kind of (navigation) requests?

Comment 3

[rugk]

No, because I want to keep the "activeTab" permission, only. I stand by my statement that it is unexpected by the user, i.e.
> As the URL is shown in the address bar, you should also deliver that to the add-on. Everything else is quite unexpected.

However, I totally see the technical problem, here. The thing is this is not a "usual download", but a download happening in a new tab, which would have no URL i.e. about:blank…

That said, if you say it is expected, I take this as a technical limitation and can close the issue of my add-on.

Comment 4

[Rob Wu [:robwu]]

> I take this as a technical limitation and can close the issue of my add-on.

Technically "about:blank" is the expected URL. You could however consider adding a work-around/fallback to your extension to get the correct URL anyway.

Previously I suggested the webNavigation API (to monitor requests via the browser.webNavigation.onBeforeNavigate event), but in your specific use case you can also request the tabs permission and then use browser.tabs.query to retrieve the tab title which provides the URL (the scheme seems to be missing, so if you don't want to guess the scheme, use the webNavigation API instead).

Since your add-on attempts to minimize the number of permissions, the "tabs" permission can probably not be part of the default permissions. But you can add it to the list of optional permissions to allow users to opt in to the functionality.

Comment 5

[rugk]

Thanks for the suggestions. However, I think this is a little too big workaround for a case that is unlikely to happen, and optionally asking for that "tab" permission in a non-creepy (asking out of nowhere) and useful way (some setting is ugly…) will likely turn out to be a UX challenge… ;)
But thanks for the ideas.