892487 - Give private browsing windows separate permission managers for opt-in

Status: RESOLVED WONTFIX

(Core :: Permission Manager, defect)

Description

[Georg Fritzsche [:gfritzsche]]

Follow-up to bug 891116, comment 3.

Via jdm on IRC:
* the permission manager was historically a singleton
* fixing it didn't make it in the private browsing changes (time constraints, cross-tree breakage potentials, ...)
* fixing it is not a high-priority right now

Given those pre-conditions, i wonder if we can't have an opt-in, throw-away, permission manager per private browsing window (initialized with the main sessions permissions).
Once we have that, we could progressively convert the tree to using it and the conversion should mostly rather easy. Helper functions to request the permission manager for the window should even make its use opaque to client code.

This at least seems to fit with the use-cases i've looked at in browser.js & browser-plugins.js - am i missing anything that would block or greatly complicate this?

Comment 1

[Josh Matthews [:jdm]]

What are the permissions you intend to manipulate with this opt-in manager? A known set of permissions will make it easier to judge the scope of the changes required.

Comment 2

[Georg Fritzsche [:gfritzsche]]

I'm currently mainly interested in the plugin click-to-play per-site settings, which are roughly: block indefinitely, activate for 1h in this session, activate for 3 months.

Those are:
* leaking out of the private window into the main session
* except one, not adoptable to per-session without bigger efforts
* from my understanding overwriting the existing permissions

There are also apparently more permissions covered by [1] and from a quick glance browser.js seems to add a few permissions that are not necessarily respecting PB.

[1] http://hg.mozilla.org/mozilla-central/annotate/c7e005de1329/browser/components/nsBrowserGlue.js#l1768

Comment 3

[(no longer active)]

How will you have this work per-window?  The permission manager as currently implemented is an XPCOM service.  It's not always easy to obtain a window context everywhere (for example, in jsm's) so if you make this a per-window thing, then you'll have to transfer the window context across the place to make it available where you need to get the permission manager service.

Comment 4

[Georg Fritzsche [:gfritzsche]]

I was of explicitly requesting the permission manager for a window at the point of use. 
Quickly scanning through the "Services.perms" results on DXR looks like it's a manageable number (admittedly ignoring the native parts for now) if adoption of passing the window context around is acceptable in principle.

Or are there different plans/options that would be more sound and/or less intrusive?

Comment 5

[(no longer active)]

(In reply to comment #4)
> I was of explicitly requesting the permission manager for a window at the point
> of use. 
> Quickly scanning through the "Services.perms" results on DXR looks like it's a
> manageable number (admittedly ignoring the native parts for now) if adoption of
> passing the window context around is acceptable in principle.

I think you basically need to look at all of the existing callers.  It's definitely doable, but it will not be an hour of work. :-)

> Or are there different plans/options that would be more sound and/or less
> intrusive?

Not that I know of.

Comment 6

[Georg Fritzsche [:gfritzsche]]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #5)
> I think you basically need to look at all of the existing callers.  It's
> definitely doable, but it will not be an hour of work. :-)

Right. So, i guess i'll go through checking and grouping the existing usage patterns when i can.

Comment 7

[Johann Hofmann [:johannh]]

I think our most likely approach for solving this problem (leaking permissions into private windows and/or out of private windows) is bug 1422056 and bug 1330467 (generally, not working with nsIURI but nsIPrincipal everywhere in permission manager and considering OAs). The approach outlined here isn't really practicable to solve in comparison.