The default bug view has changed. See this FAQ.

load plugins from $profile/plugins

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Toolkit
Startup and Profile System
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: ted, Assigned: ted)

Tracking

({verified1.9.1})

Trunk
mozilla1.9.2a1
verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking1.9.1 -, status1.9.1 .2-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

8 years ago
Created attachment 358878 [details] [diff] [review]
append $profile/plugins to NS_APP_PLUGINS_DIR_LIST

Currently we don't load plugins from $profile/plugins. It's not generally a problem, but I'm trying to run Mochitest on a packaged build, and nowadays that means we need the test plugin to run all the tests, but there's no easy place to put it. If we support $profile/plugins then I can get it in the Mochitest profile, and all is good.
Attachment #358878 - Flags: superreview?(joshmoz)
Attachment #358878 - Flags: review?(benjamin)
(Assignee)

Updated

8 years ago
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
Attachment #358878 - Flags: review?(benjamin) → review+

Comment 1

8 years ago
Comment on attachment 358878 [details] [diff] [review]
append $profile/plugins to NS_APP_PLUGINS_DIR_LIST

Why can't you just use LoadDirsIntoArray like above the code you added?
(Assignee)

Comment 2

8 years ago
I could, but that takes an nsCOMArray<nsIFile>, so I'd have to create one. I can give it a shot and see if it's more or less lines of code.
LoadDirsIntoArray does something entirely different. It doesn't make sense to use it here.
(Assignee)

Comment 4

8 years ago
Created attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

Actually, it turns out to be pretty straightforward to do it that way. It's slightly less code, too, and it actually looks more consistent with the surrounding code to me.
(Assignee)

Comment 5

8 years ago
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

Alternate approach. Thoughts?
Attachment #359514 - Flags: review?(benjamin)
Attachment #359514 - Flags: review?(benjamin) → review+
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

It feels a bit odd, but I guess it's less code.

Updated

8 years ago
Attachment #358878 - Flags: superreview?(joshmoz)

Updated

8 years ago
Attachment #359514 - Flags: review+
(Assignee)

Updated

8 years ago
Attachment #358878 - Attachment is obsolete: true
(Assignee)

Comment 7

8 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/dbe9086219a6
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

8 years ago
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

Want this on branch to unblock bug 383136.
Attachment #359514 - Flags: approval1.9.1?
Blocks: 491910
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

a191=beltzner
Attachment #359514 - Flags: approval1.9.1? → approval1.9.1+
(Assignee)

Comment 10

8 years ago
Trying to figure out a way to test this, can't really use the test plugin because that already exists in the app plugins dir.
Flags: in-testsuite?
Attachment #359514 - Flags: approval1.9.1+ → approval1.9.1-
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

Revoking approval. We're cutting back on potential churn here. We can try again for 3.5.1
The ability to load plugins through the profile would be of great benefit to talos.  bug 483902 would (will) be fixed by upgrading flash.  Doing so on all the active talos boxes would take a good long downtime and lots of manpower, being able to roll out new plugins through the profile means that it can be upgraded on the buildbot master and automagically pushed to all the slaves.

I would really like to see this on 1.9.1.  It would also be useful on Firefox3.0, but I can understand why backporting might be considered not valuable enough for the effort.
Totally understand the "no churn" comment.

However, nom-ing for 3.5.x because we'll need this landed on mozilla-191 before we can stop running build-and-unittest, and only run unittests on packaged builds. And all the resulting yummy goodness that gets us.
Flags: wanted1.9.1.x?
Blocks: 496534
Attachment #359514 - Attachment description: using LoadDirsIntoArray → using LoadDirsIntoArray [Checkin: Comment 7]
Whiteboard: [needs 1.9.1 landing: needs approval]
Target Milestone: --- → mozilla1.9.2a1
Version: unspecified → Trunk
(Assignee)

Comment 14

8 years ago
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

Can we get this on the branch to fix the packaged unittest builds from being perma-orange? It's baked on trunk for a long, long time.
Attachment #359514 - Flags: approval1.9.1.1?
Who can approve and land this on 1.9.1? 

Its blocking rollout of tp4 on that branch, which is blocking turnoff of fast talos machines on that branch.
Attachment #359514 - Flags: approval1.9.1.1? → approval1.9.1.2?
(In reply to comment #15)
> Who can approve and land this on 1.9.1? 
> 
> Its blocking rollout of tp4 on that branch, which is blocking turnoff of fast
> talos machines on that branch.

beltzner, sam: are these flags correct for requesting approval to land test changes on mozilla-191?
blocking1.9.1: --- → ?
Flags: blocking1.9.0.13?
Attachment #359514 - Flags: approval1.9.1.2? → approval1.9.1.2+
Comment on attachment 359514 [details] [diff] [review]
using LoadDirsIntoArray
[Checkin: Comment 7]

a1912=beltzner
blocking1.9.1: ? → -
status1.9.1: --- → wanted
Flags: wanted1.9.1.x?
(In reply to comment #17)
> (From update of attachment 359514 [details] [diff] [review])
> a1912=beltzner

beltzner: cool, thanks.

ted: any chance you can land this, even though you are at OSCON this week?
Fixed on 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/06bca4693d14
status1.9.1: wanted → .2-fixed
Whiteboard: [needs 1.9.1 landing: needs approval]
(In reply to comment #16)
> beltzner, sam: are these flags correct for requesting approval to land test
> changes on mozilla-191?

You might want approval (or wanted) but probably not blocking on 1.9.0.x.
Flags: blocking1.9.0.13?
Whiteboard: [fixed1.9.1.2]
Whiteboard: [fixed1.9.1.2]

Comment 21

8 years ago
Verified
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.