252554 - vacate extensions/cookie

Status: NEW

(Firefox Build System :: General, defect)

Description

[[e-mail]]

subsequent to bug 210561, extensions/cookie now contains just permissionmanager
and permissions-related stuff... it's high time we busted it up for good, and
moved these components into more appropriate places. it would be nice to get a
handle on this soon, since mvl is planning to add more permissions-related files
in bug 240070.

i made a firefox-specific proposal in
http://bugzilla.mozilla.org/show_bug.cgi?id=210561#c11 that i think will do this
nicely. i have implemented this locally with no complications. to paraphrase:

a) toolkit/components/permmgr: nsIPermission, nsIPermissionManager, and permmgr
backend impl.

b) browser/components/permissions: nsIImgManager, imgmanager &
popupwindowmanager impls, cookie permission impl, and all related UI. (this is
app-specific stuff.)

there is one hitch though - nsIPermissionManager currently lives in
netwerk/base/public, a totally bogus and temporary hack by dveditz (since
xpinstall now requires nsIPermissionManager, and tier 50 cannot depend on tier
99 extensions). toolkit and xpinstall are both tier 50, so technically my
proposal works, but it requires adding a toolkit dependency to xpinstall.
bsmedberg said this is probably okay, as long as there are no #ifdefs in the
permmgr backend, which there won't be. (if xpinstall depends on toolkit, that
means seamonkey also depends on toolkit.)

if this ends up being a problem, we can fork stuff and put nsIPermissionManager
in xpfe as well. the permmgr backend cannot continue to live in extensions,
because it is becoming more of a core component (viz. xpinstall, likely with
more to follow). so while renaming extensions/cookie to extensions/permission
might seem nice, it won't work. i think making seamonkey depend on toolkit here
would be the nicest solution, simply because it avoids unnecessary forking, but
it doesn't really matter ;)

part (b) can go to extensions/permission and be shared by the apps, or be
forked, it doesn't really matter. (does tbird want imgmgr? if so, and it can be
a common impl between mail and browser, maybe we don't want it to live in browser.)

thoughts?

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

I don't like the idea of makeing seamonkey depend on toolkit. Toolkit has
different treerules from seamonkey. That has to be solved first.

netwerk might not be a bad place for the permmgr. It is network related. It only
works with uris :)

For part b), browser may seem nice, but i'm against unneeded forking. If you
don't change anything, don't fork. Here you don't change anything (except maybe
for some mailnews checks, but you can #ifdef them out)

Comment 2

[Mike Connor [:mconnor]]

(In reply to comment #1)
> I don't like the idea of makeing seamonkey depend on toolkit. Toolkit has
> different treerules from seamonkey. That has to be solved first.

/toolkit is already required to build seamonkey.  Also, what specifically about
the treerules needs to be solved?

> For part b), browser may seem nice, but i'm against unneeded forking. If you
> don't change anything, don't fork. Here you don't change anything (except maybe
> for some mailnews checks, but you can #ifdef them out)

we might put it all in toolkit, dwitte and I discussed this elsewhere.  We can
provide a legacy fork for seamonkey, but that's a limited-time necessary deal.

Comment 3

[Daniel Veditz [:dveditz]]

Future things we may like to make depend on permission manager are per-site use
of external protocol handlers and plugins. Lower-level code can deal with a
service not being installed and fall back to a global default, but it seems like
we're going to keep needing the iface earlier than tier 50.

Maybe somewhere in embedding (along with some of the similarly misplaced
password interfaces)?

Comment 4

[[e-mail]]

hmm... how would embedding be better than netwerk?

as an aside, we have a lovely nsIPopupWindowManager that lives in appshell,
which basically just wraps nsIPermissionManager so that dom (tier 9) can use it.
i wonder if we could even kill that wrapper if nsIPM lived in a sane place.

anyway, maybe darin has some thoughts here. we have some random xpfe dirs going
into tier 9, but i'm guessing that is not a good thing... otherwise, maybe we
could just make toolkit/components/permmgr tier 9. otherwise, netwerk seems like
the best place for it to live, if we can't have toolkit :/

Comment 5

[Darin Fisher]

seamonkey is going to start depending on toolkit/components/gnome in the near
future i believe.  so, there's convention for making seamonkey depend on
portions of toolkit.

fwiw, i'm starting to think that it might make sense to have necko use
nsIPermissionManager for some things, so it might make sense to keep the
interface in necko.

Comment 6

[Robert Kaiser]

(In reply to comment #5)
> seamonkey is going to start depending on toolkit/components/gnome in the near
> future i believe.  so, there's convention for making seamonkey depend on
> portions of toolkit.

If SeaMonkey is to survive, it will very likely (have to) be ported to toolkit
anyway, so I'd guess it's no problem to move something into toolkit that is used
by SeaMonkey. It's always better than forking more and more stuff.

Comment 7

[Ian Neal]

On the UI (js/xul) side of things I've posted some proposals on
https://bugzilla.mozilla.org/show_bug.cgi?id=277097#c5

Comment 8

[[e-mail]]

the next step, i think, will be moving permmgr backend into necko. once this is
done, and mvl kills imgmgr, we'll be as close to fixing this bug as we'll get.
the cookie permission code (incl cookie prompt dialog) can remain living in
extensions/cookie, since they'll always be shared between the apps - unless
someone comes up with a better idea to share them ;)

Comment 9

[[e-mail]]

serge, don't touch my bugs without my permission.

Comment 10

[[e-mail]]

Reassigning to nobody. If anyone wants to work on this, feel free!