Provide an API to show the downloads manager

REOPENED
Assigned to

Status

()

Toolkit
WebExtensions: Frontend
P3
normal
REOPENED
8 months ago
6 months ago

People

(Reporter: mixedpuppy, Assigned: mixedpuppy)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [downloads][design-decision-approved]triaged)

(Assignee)

Description

8 months ago
tab.create fails opening about:downloads.  I guess this is similar to bug 1261289.
(Assignee)

Comment 1

8 months ago
Use case would be a newtab override (bug 1234150) that wants to provide links to open various browser controls such as an about:history (doesn't exist yet) or about:downloads page.

Comment 2

8 months ago
This is intentional. Extensions can open unprivileged about: pages that can be opened by ordinary web pages, but there are serious security and compatibility implications with allowing them to open privileged pages.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX

Comment 3

8 months ago
Could you outline those concerns?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 4

8 months ago
(In reply to Andy McKay [:andym] from comment #3)
> Could you outline those concerns?

Not as well as some people. There are various security bugs related to the restrictions preventing web content from loading those pages, and some that I don't have access to about the more stringent restrictions that we've added recently.

The biggest security issues tend to come from the side-effects that those pages often have, especially when passed query parameters, and other issues related to click-jacking.

Even with security issues aside, there are compatibility issues. The UI and URLs of those pages often change. about:downloads exists now, and currently opens in a tab, but that hasn't always been the case, and probably won't always be the case. So if we want to give extensions the ability to open those kinds of pages, we should do it via some kind of appropriate UI method rather than giving them the ability to arbitrarily load the URLs.

Updated

8 months ago
Flags: needinfo?(dveditz)

Comment 5

8 months ago
Feels like bug 1227462 is relevant here.
(Assignee)

Comment 6

8 months ago
Given that we don't need to be 100% compat, I think an alternate UI api to do these things is a fine approach.

If we do eventually want to do away with old school addons, we will need some of these things for our partner distributions.

Updated

8 months ago
Component: WebExtensions → WebExtensions: Frontend
Summary: add ability to open browser content pages (ie. about: pages) → Provide an API to show the downloads manager
Whiteboard: [downloads]

Updated

8 months ago
Flags: needinfo?(amckay)
Whiteboard: [downloads] → [downloads][design-decision-needed]
I'm not entirely sure what Andy was asking me. People install extensions to do things that mere web pages cannot; limiting what they can do to what a web page can do is going to leave people disappointed. Maybe we need to add a permission that allows a Web Extension to enumerate the non-web-accessible URLs it wants to open. We may also decide there are some URLs that are "safe enough" even though we don't let web pages use them. I hope view-source: falls into that category (bug 1261289), and "safe" about: urls (formerly openable by web pages) might. The download manager runs at a higher privilege level so I'd want to have a permission for that one.

An API to "show the download manager" is different than the ability to open/use an arbitrary URL. It's more limited, which has its plusses and minuses. The plusses are on the security side--less for me to worry about--but might not be as flexible for extension authors.
Flags: needinfo?(dveditz)

Comment 8

8 months ago
Sorry, in comment 4, Kris addresses security concerns that he doesn't have access to each which leaves us kind of guessing what to do. If you'd rather not talk about that in this bug (or make it security sensitive, that's cool). 

Agree with your comments, an API to show the downloads manager sounds cool but what access to the window or tab do I get after that? Do we need more than just showing it? It feels like if we limit to certain actions like, show a window, we'll get into a rabbit hole of more and more requests.

A permission feels like a cop out though, we've said all these things might be a problem and just stuffing them behind a permission and pushing that risk to the user. 

So my first guess is let's make an explicit permission, then poke holes in that for certain URLs that are safe enough and see if we can take baby steps towards something we can use, but again those vague security worries concern me.
Flags: needinfo?(amckay)

Comment 9

8 months ago
(In reply to Andy McKay [:andym] from comment #8)
> Agree with your comments, an API to show the downloads manager sounds cool
> but what access to the window or tab do I get after that? Do we need more
> than just showing it? It feels like if we limit to certain actions like,
> show a window, we'll get into a rabbit hole of more and more requests.

Giving any direct access to about:downloads, aside from the ability to open it
in a tab, is completely out of the question. It's fully chrome-privileged, so
any direct access would be a huge privilege escalation.

But I'm not a fan of even allowing them to load the URL directly. That ties
our hands the next time we want to change the implementation. It means that we
can't remove about:downloads, we have to continue allowing it to open in a new
tab, we can't prevent extensions from opening multiple new copies rather than
just focusing an existing one, we can't change the default behavior to open it
in, say, a sidebar or a panel.

For the case of opening the download manager, or other things like
about:addons or about:preferences, an API is the obvious choice. There may be
other cases where we might want to allow direct access to open the URLs, but I
can't think of any immediately obvious examples.
(Assignee)

Comment 10

8 months ago
I'm not clear on why tab.create would result in elevated privileges (and of course we're not looking to do that).  I see there is executeScript, which seems blockable for privileged pages.  There is message passing, which seems like something that shouldn't need to be worried about (ie. if about:downloads supported message passing, why wouldn't we allow an addon talk to it?).

Compatibility over concern about special handling of tabs/urls for privileged content pages seems worth thinking about.  eg. We could prevent multiple tabs and ignore options (sidebar/panel/etc) of certain pages if it makes sense.  

Regarding removal of content pages; In some of these cases it's hard to imagine the functionality not existing, but you never know.  I've always had the impression that we're moving towards content pages rather than away.  In that case, we shouldn't be a afraid of making a page that says "oops, addon xyz tried opening a page that does not exist in Firefox."  That page could even be an opportunity to direct users to getting an addon that may substitute the features we removed.
(In reply to Shane Caraveo (:mixedpuppy) from comment #10)
> I'm not clear on why tab.create would result in elevated privileges (and of
> course we're not looking to do that).  I see there is executeScript, which
> seems blockable for privileged pages.  There is message passing, which seems
> like something that shouldn't need to be worried about (ie. if
> about:downloads supported message passing, why wouldn't we allow an addon
> talk to it?).

I'm not especially worried that just opening the tab will cause security
issues, unless we also allow query arguments or the like. Things like
`executeScript`, or loading into a subframe, are more of a concern. I wouldn't
be surprised if other features of the tabs API caused issues, but they're not
really my primary concern.

> Compatibility over concern about special handling of tabs/urls for
> privileged content pages seems worth thinking about.  eg. We could prevent
> multiple tabs and ignore options (sidebar/panel/etc) of certain pages if it
> makes sense.  

We could, but if we're going to give it special handling anyway, I think it
makes much more sense to just provide an API to open it, potentially with
additional features, such as highlighting a specific download.

> Regarding removal of content pages; In some of these cases it's hard to
> imagine the functionality not existing, but you never know.  I've always had
> the impression that we're moving towards content pages rather than away.

We are now, but there's no telling how long that will be the case, or how long
before we decide to integrate the downloads manager into some other content
page, or UI feature, or remove support for the in-content version in favor of
just the panel or a sidebar.

We could try to work around these things by letting add-ons just open a tab
with about:downloads and then implementing some kind of special behavior, but
I can't think of a good reason that we'd want to do that rather than just
provide an API that Does the Right Thing regardless of our current
implementation.

Comment 12

8 months ago
(In reply to Kris Maglione [:kmag] from comment #11)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #10)
> > I'm not clear on why tab.create would result in elevated privileges (and of
> > course we're not looking to do that).  I see there is executeScript, which
> > seems blockable for privileged pages.  There is message passing, which seems
> > like something that shouldn't need to be worried about (ie. if
> > about:downloads supported message passing, why wouldn't we allow an addon
> > talk to it?).
> 
> I'm not especially worried that just opening the tab will cause security
> issues, unless we also allow query arguments or the like. Things like
> `executeScript`, or loading into a subframe, are more of a concern. I
> wouldn't
> be surprised if other features of the tabs API caused issues, but they're not
> really my primary concern.

We could probably get a list of those APIs that would cause problems. Of course things like content scripts would be way out. Its worth noting that you can already get things like the about:addons tab and interact using our APIs, so perhaps we could harden that as well.

> We could, but if we're going to give it special handling anyway, I think it
> makes much more sense to just provide an API to open it, potentially with
> additional features, such as highlighting a specific download.

Additional features for downloads would be great, maybe that would be a seperate bug though.

> We could try to work around these things by letting add-ons just open a tab
> with about:downloads and then implementing some kind of special behavior, but
> I can't think of a good reason that we'd want to do that rather than just
> provide an API that Does the Right Thing regardless of our current
> implementation.

My main concern there is that you end up duplicating a whole API off into another API. In the end if there's a tabs.createDownloads or tabs.createAddonManager, I would have no problem with that, since we aren't compatible with Chrome anyway.
(In reply to Andy McKay [:andym] from comment #12)
> > We could try to work around these things by letting add-ons just open a tab
> > with about:downloads and then implementing some kind of special behavior, but
> > I can't think of a good reason that we'd want to do that rather than just
> > provide an API that Does the Right Thing regardless of our current
> > implementation.
> 
> My main concern there is that you end up duplicating a whole API off into
> another API. In the end if there's a tabs.createDownloads or
> tabs.createAddonManager, I would have no problem with that, since we aren't
> compatible with Chrome anyway.

It think it would be more like `downloads.showDownloads({...})` or
`management.openOptionsPage({extensionId})` (ala `runtime.openOptionsPage`),
or `bookmarks.openBookmarkManager({folderId})`, where the methods would be
part of the appropriate API, and follow the same conventions as the rest of
that API.
(Assignee)

Comment 14

8 months ago
I think I like the use of the appropriate api especially as that provides the ability to open non-tab based ui without being weird.  However, that creates a need for an api call for each item we might want to expose, rather than a generic ability to expose pages via a single api call.  I'm on the fence basically, I have a need to support certain pages for a partner (some which may not have content pages yet) and don't mind specific APIs, but I prefer a more open system to avoid additional effort (like this bug) down the road.

Comment 15

8 months ago
I'm happy with the suggestion of the API in comment 13. We'll probably need to file bugs for all the other pages too.

Updated

7 months ago
Priority: -- → P3
Whiteboard: [downloads][design-decision-needed] → [downloads][design-decision-approved]triaged

Updated

6 months ago
Assignee: nobody → mixedpuppy
You need to log in before you can comment on or make changes to this bug.