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?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8alpha3
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)
(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.
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)?
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 :/
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.
(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.
On the UI (js/xul) side of things I've posted some proposals on https://bugzilla.mozilla.org/show_bug.cgi?id=277097#c5
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 ;)
Target Milestone: mozilla1.8alpha3 → Future
Assignee: dwitte → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---
serge, don't touch my bugs without my permission.
Assignee: nobody → dwitte
Target Milestone: --- → Future
Assignee: dwitte → nobody
Component: Build Config → Build Config
Product: SeaMonkey → Core
QA Contact: build-config → build-config
Reassigning to nobody. If anyone wants to work on this, feel free!
Assignee: dwitte → nobody
You need to log in before you can comment on or make changes to this bug.