826531 - Provide a way for the Gaia Browser App to enumerate page permissions

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Bug 826528 specifies a feature where users can modify/clear remembered permission choices for web pages loaded in the browser app. From discussions on IRC, this may need a platform API to expose these permissions to the browser. 

Can we give the browser "permissions" permission so that it could manage the permissions?  This sounds super dangerous though - would it be better if we provided a way for the browser to only manage the permissions of the web pages, and not apps?

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure if we should let the *browser* enumerate or change permissions. We certainly could do that though we need to restrict access to only *remove* remembered permissions, or set them to "deny". We can't let the browser set permissions to "allow".

And the browser must only be allowed to set permissions for pages with the browserFlag=true and the appid=<appid of browser app>.

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

As per ben's comment in bug 826528, we also need to think about bookmarked pages, and everything.me

I am not sure what app these run under: system and homescreen respectively maybe?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

They both run under the system app.

I think they definitely should be configured through the settings app in the same place where you configure app permissions. We should make the experience of homescreen-bookmarked pages and everything.me apps as much like "normal" apps as possible.

Comment 4

[Mounir Lamouri (:mounir)]

PermissionSettings could work in two modes with "permissions" and with "browser-permissions". If the app has the later permission, it will be allowed to deny or reset any permission that applies to its own app (aManifestURL is its own manifest) and aBrowserFlag will have to be true. In addition, *maybe* we could allow the app to allow some permissions if the app has the permission granted.

Comment 5

[Lawrence Mandel [:lmandel] (use needinfo)]

It's too late in the v1 schedule for this type of feature work. In triage we commented on the ability to clear this data using the existing "Clear cookies and stored data". If this option doesn't clear permissions can we modify it to also clear permissions for v1 in order to give the user the ability to clear their permissions with minimal change?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Clearing private data should clear permissions already.

Comment 7

[Mounir Lamouri (:mounir)]

(In reply to Jonas Sicking (:sicking) from comment #6)
> Clearing private data should clear permissions already.

No. Permissions are only cleared when an application is uninstalled. Changing that behaviour would be trivial though.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah. Maybe we should hook that up for now as a stop-gap until we have a proper solution which allows browser apps to have more control over permissions in their browser-cookie-jar.

Comment 9

[Paul Theriault [:pauljt] (no longer reading bugmail)]

That works for the Browser, but what about pages which are loaded as a child of the System app (bookmarks, everything.me) ?  I just tested this, and currently the browser only clears its own cookies, not cookies for bookmarked pages.

So I think there are two things to do here:
1. Make the browser "clear private data" button forget remembered permissions
2. Add code to clear cookies/data/remembered permissions when a bookmark/everything.me app is removed from the homescreen

Thoughts?

Comment 10

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So I think this bug should be for "Make the browser "clear private data" button forget remembered permissions" and I will move point to bug 826528. And re-nom'ing both with this reduced scope.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Bug 827050 already covers what you morphed this bug into. Since that bug already is +'ed and has a patch, I'm minusing this bug and morphing it back to what it was originally filed on.

In general, don't morph bugs since they get very confusing since early comments don't apply to the new morphed meaning.

It might even be worth WONTFIXing this bug and figuring out a comprehensive solution to do for v2

Comment 12

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Ah ok, sorry didnt know that, sounds like a plan to me.

Comment 13

[Paul Theriault [:pauljt] (no longer reading bugmail)]

as per c11.