Closed Bug 416246 Opened 14 years ago Closed 11 years ago

Implement hook scripts for extension actions

Categories

(Toolkit :: Add-ons Manager, enhancement)

enhancement
Not set
normal

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.
Keywords: qawanted
Whiteboard: dupeme
Product: Firefox → Toolkit
Blocks: 242071, 340339
Keywords: qawanted
Summary: Extension manager should allow extension-provided code to run at certain times → Implement hook scripts for extension actions
Whiteboard: dupeme
Severity: normal → enhancement
Blocks: 256509
Target Milestone: --- → mozilla2.0
Target Milestone: mozilla2.0 → mozilla1.9.2
Target Milestone: mozilla1.9.2 → mozilla1.9.3
Duplicate of this bug: 632637
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: 11 years ago
Resolution: --- → WONTFIX
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 → ---
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.
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.
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?
(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.
WONTFIX per the previous comments.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WONTFIX
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.