Closed
Bug 416246
Opened 18 years ago
Closed 15 years ago
Implement hook scripts for extension actions
Categories
(Toolkit :: Add-ons Manager, enhancement)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
WONTFIX
mozilla2.0
People
(Reporter: eyalroz1, Unassigned)
References
(Blocks 1 open bug, )
Details
The extension manager should allow extensions to indicate JS code to run before they have been installed, and after the restsrt, i.e. when they are first used.
This would be very useful for such purposes as migrating old extension-related preferences to match new versions, to place your extension's button on the toolbar by default, etc.
What extension developers currently have to do is always load some JS which checks a have_run_special_code_already pref which is set to true after running the code for the first time... quite a waste.
| Assignee | ||
Updated•17 years ago
|
Product: Firefox → Toolkit
Updated•17 years ago
|
Updated•17 years ago
|
Severity: normal → enhancement
Updated•17 years ago
|
Target Milestone: --- → mozilla2.0
Updated•17 years ago
|
Target Milestone: mozilla2.0 → mozilla1.9.2
Updated•17 years ago
|
Updated•16 years ago
|
Target Milestone: mozilla1.9.2 → mozilla1.9.3
Comment 2•15 years ago
|
||
Restartless extensions have this sort of thing now, I'm not interested in extending support for that to non-restartless add-ons at this point.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
| Reporter | ||
Comment 3•15 years ago
|
||
Many or most extensions are not of the restartless variety. The official documentation says (https://developer.mozilla.org/en/Extensions/Bootstrapped_extensions):
"These are special extensions that, instead of using overlays to apply their user interface to the application, programmatically insert themselves into the application."
Most extensions are not special; they do not fit that bill; they use overlays - as well they should... and they need these hooks.
Also, please talk to people about closing their bugs before actually doing so.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 4•15 years ago
|
||
Eyal, Dave is the owner of the add-ons manager module and has the authority to resolve bugs as wontfix.
http://www.mozilla.org/projects/toolkit/review.html
Though Dave is reasonable I suspect that this bug will just be wontfix in part due to the nature of non restartless add-ons since the work to notify them when they are disabled is to say the least a difficult problem along with the preference for add-ons to use be of the restartless variety.
Comment 5•15 years ago
|
||
The hope is that the majority of extensions will naturally move over to the SDK while non-restartless add-ons can detect most of the cases manually through the API.
I believe that the complexity of implementing this for non-restartless add-ons is high enough that it isn't worth considering this at this point.
| Reporter | ||
Comment 6•15 years ago
|
||
I think it's not reasonable to expect most extension authors to start writing code to dynamically insert their overlays; rather, one would assume someone would modify the SDK to spare us that. After all, we're specifying what needs to be loaded, why should each extension have its own loading code?
Also, I believe many extension authors don't like the SDK and are comfortable with writing extensions the way we do now. Perhaps over the years this will change, but not for a long while.
Finally, I don't think it should be complex to implement at least some hooks for regular extensions: We're talking about just running pieces of JS, specified, say, in the install.rdf, upon installation, removal, disabling, or the first start after installation. Is there a difficulty in doing any of this of which I'm not aware?
Comment 7•15 years ago
|
||
(In reply to comment #6)
> I think it's not reasonable to expect most extension authors to start
> writing code to dynamically insert their overlays; rather, one would assume
> someone would modify the SDK to spare us that. After all, we're specifying
> what needs to be loaded, why should each extension have its own loading code?
>
> Also, I believe many extension authors don't like the SDK and are
> comfortable with writing extensions the way we do now. Perhaps over the
> years this will change, but not for a long while.
We aren't going to force people to switch to the SDK, at least for the future that I can see, developers can choose what type of extension they want based on the features they need. And the SDK certainly can and has grown as needs demanded.
> Finally, I don't think it should be complex to implement at least some hooks
> for regular extensions: We're talking about just running pieces of JS,
> specified, say, in the install.rdf, upon installation, removal, disabling,
> or the first start after installation. Is there a difficulty in doing any of
> this of which I'm not aware?
There was quite a lot of complexity involved in making the script running parts of restartless extensions work (and even now there are still some bugs left with it) and in the case of restartless extensions these things aren't a nice-to-have feature but a necessity for allowing the extension to work. For non-restartless extensions the scripts would have to be called at different times meaning that it isn't just as straightforward as re-using all the existing code and so even more code would have to be added to support this.
Given that (ignoring tricky edge cases) extensions can already detect the cases that we'd have added hooks for anyway I'm not inclined to spend any more time on this, nor would I expect anyone else within Mozilla to volunteer to do so given the enthusiasm everyone has for restartless add-ons and the SDK. I also would be unlikely to accept a contributed patch to add this unless it turned out to be less code change than I predict.
Comment 8•15 years ago
|
||
WONTFIX per the previous comments.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → WONTFIX
| Reporter | ||
Comment 9•15 years ago
|
||
Well, as it seems I'm the only one complaining, fine.
(Not sure what you mean by extensions being able to detect the events for which hooks were requested; this only true partially and in a kludgy way AFAIK.)
You need to log in
before you can comment on or make changes to this bug.
Description
•