Open Bug 467751 Opened 13 years ago Updated 13 years ago
Debian System Plugin Location - XRE Part
(Most likely wrong component ... file affected is in toolkit/xre/; why doesnt toolkit have a "General" component?) Bug 440506 landed support for a legacy plugin location /usr/lib/mozilla/plugins. I don't agree that /usr/lib/mozilla is really a good location for that, however the patch committed forgot the toolkit/xre/ part.
Component: XULRunner → Startup and Profile System
QA Contact: xulrunner → startup
from ubuntu xulrunner-1.9.1 packaging branch
Assignee: nobody → asac
Attachment #351167 - Flags: review?(mconnor)
Comment on attachment 351167 [details] [diff] [review] for 1.9.1 I think Benjamin is the best reviewer for this.
Attachment #351167 - Flags: review?(mconnor) → review?(benjamin)
I don't see what kind of need the toolkit/xre part fulfils.
Comment on attachment 351167 [details] [diff] [review] for 1.9.1 I think mh is correct here: the default plugins provider already provides this key: http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsAppFileLocationProvider.cpp#596 This result is then *aggregated* with the nsXREDirProvider version, see here: http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsXREDirProvider.cpp#777 There should be no need for this patch. I would love to have a unit-test for it, though!
Attachment #351167 - Flags: review?(benjamin) → review-
(In reply to comment #4) > I would love to have a unit-test for it, though! AFAIK, this is not possible, as it would rely on files being installed in a system directory, which the build/check scripts usually won't have access to. The only way I see to circumvent this would be to use something like fakechroot, but this may be overkill.
Oh, I didn't mean anything that complicated. I just meant to ask the directory service to make sure that NS_SYSTEM_PLUGINS_DIR was included in NS_APP_PLUGINS_DIR_LIST (if NS_SYSTEM_PLUGINS_DIR is present at all).
You need to log in before you can comment on or make changes to this bug.