Closed Bug 627209 Opened 13 years ago Closed 13 years ago

Support non-bootstrapped (XUL) extensions on Mozilla 2

Categories

(Add-on SDK Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: asqueella, Assigned: asqueella)

References

Details

Attachments

(1 file)

All that's needed is:
- let the extension specify a static classID for the harness component (bug 626059).
- add a NSGetFactory() entry point
- make the harness component register for profile-before-changed instead of  app-startup to run on startup, since only the former works on both 1.9.2 and 2.0

I'm also going to make this tested by adding a XUL extension template for 'cfx init' and including it in the test run, but that work is not ready yet.
> I'm also going to make this tested by adding a XUL extension template for 'cfx
> init' and including it in the test run, but that work is not ready yet.

It's here by the way: https://github.com/nickolay/addon-sdk/tree/WIP-xul-extensions (will be rebased)
Atul, could you take a look?
Attachment #510128 - Flags: review?(avarma)
Overall, this looks cool, but I'm so rusty on the intricacies of the original code you're modifying that I'm not sure I'm qualified to r+ it... Then again, I'm not sure if *anyone* is super familiar with this code anymore.

The main things I think we need to make sure still work with this patch applied:

  * 'cfx develop'. Often changes to this part of the code unintentionally break 'cfx develop', in part because it makes deep hooks into this code.

  * The Add-on builder helper addon at https://github.com/mozilla/addon-builder-helper. It relies on the same 'development-mode' package that 'cfx develop' does, so when 'cfx develop' breaks, it does too.

  * Normal restartless addon functionality (obviously).

As long as those things still work, I think this patch is probably good to go. Thanks for working on this, Nickolay!
Nickolay: have you managed to test the functionality Atul mentions in comment 4 to make sure it still works?

Brian: I noticed you commented in the pull request.  Any insight into potential regressions from this change?
Myk, not yet (I think I tested 1 and 3, but not 2 before opening the pull request; I'd like to retest to make sure). This will be first thing I'll do when I have time.

Brian's comment was for the commit already landed in bug 626059. That comment was not news to me and there shouldn't be any regressions from that change.
OK, I tested the scenarios Atul mentioned in comment 0 using:
- Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b13pre) Gecko/20110226 Firefox/4.0b13pre
- https://github.com/mozilla/addon-builder-helper/commit/1fce8da13eed829fc03fa3c28608e0d83e31cf03
- https://github.com/mozilla/addon-sdk/commit/e0d46ecdbd3e7218bc51468883efe292545e2528

Nothing seems broken: I built the addon builder helper with 'cfx xpi', installed it into a running Firefox instance and was able to install/uninstall an addon from https://builder.addons.mozilla.org/addon/1000529/latest/ (the addon bar icon appeared and disappeared).

cfx develop followed by cfx {run|test} --use-server worked fine (judging by the widget in the status bar again) for reddit-panel example.
I meant comment 4, not 0, of course.
Comment on attachment 510128 [details]
pointer to the pull request

My tests similarly suggest that this change is benign.  And profile-after-change is the recommended notification for extensions to observe <https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Category_registration>.  So this seems like a fine change.
Attachment #510128 - Flags: review?(avarma) → review+
Thanks, Myk!
Blocks: 641215
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: