MozillaZine

RFC: Extension Developer Extension

Talk about add-ons and extension development.
Ted Mielczarek
 
Posts: 1269
Joined: November 5th, 2002, 7:32 am
Location: PA

Post Posted May 9th, 2005, 5:38 am

As much as I hate bumping my own topic, I'd appreciate feedback on the JS Injector if anyone has used it. Any thoughts?

asqueella
 
Posts: 4019
Joined: November 16th, 2003, 3:05 am
Location: Russia, Moscow

Post Posted May 10th, 2005, 9:50 pm

oops, always forgot. http://mozilla.doslash.org/stuff/extensiondev-delta.zip
I can make prefs window if you like.

I don't get the point of JS Injector.

Ted Mielczarek
 
Posts: 1269
Joined: November 5th, 2002, 7:32 am
Location: PA

Post Posted May 11th, 2005, 2:32 pm

asqueella wrote:oops, always forgot. http://mozilla.doslash.org/stuff/extensiondev-delta.zip
I can make prefs window if you like.

I don't get the point of JS Injector.


asqueella wrote:1- can we have a drop-down list in Javascript Environment that allows us to choose what window to run the code in?


You asked for that a while ago. I made it even easier, you just put your javascript in a file, and execute that against any window.

The xuledit changes look cool, I'll try to get those in soon.

asqueella
 
Posts: 4019
Joined: November 16th, 2003, 3:05 am
Location: Russia, Moscow

Post Posted May 11th, 2005, 2:51 pm

Hm, I wanted a drop-down in the JS Environment. Creating a separate file to execute some code isn't convenient. Anyways, the multiline JS console suits my needs well.

Ted Mielczarek
 
Posts: 1269
Joined: November 5th, 2002, 7:32 am
Location: PA

Post Posted May 11th, 2005, 5:42 pm

asqueella wrote:Hm, I wanted a drop-down in the JS Environment. Creating a separate file to execute some code isn't convenient. Anyways, the multiline JS console suits my needs well.


See, I'd rather edit my javascript in Emacs with syntax highlighting and all that good stuff. I agree that the multiline JS Shell mostly removes the need for the JSEnv, and I think the JS Injector makes it easy to test whole bunches of code in a window.

asqueella
 
Posts: 4019
Joined: November 16th, 2003, 3:05 am
Location: Russia, Moscow

Post Posted May 11th, 2005, 6:00 pm

I think a cool feature then would be the ability to inject the file on some kind of signal from outside -- to be able to "run" the JS code without having to open the Injector window first.

meilon

User avatar
 
Posts: 7
Joined: May 22nd, 2005, 6:24 am
Location: Germany

Post Posted May 22nd, 2005, 6:31 am

Hiho,
i have just started in developing extensions for my FireFox. *Thumbs Up* for your super extension :D

I have a problem right now with building my extension. I have searched and found the chrome.manifest. It seems that your plugin doesn't support this great file format, its much easier to understand.

Could you implement this feature into you extension? And what about helping starters like me and integrate a Filegenerator for the javascript and xul files in the correct dir? Only generate them and put them in the correct folder - is this possible?

meilon

Ted Mielczarek
 
Posts: 1269
Joined: November 5th, 2002, 7:32 am
Location: PA

Post Posted May 24th, 2005, 6:24 am

I've been meaning to make a "new extension wizard" for some time now. I should also support the chrome.manifest format. Hopefully I'll have time to do that soon.

ebricca
 
Posts: 3
Joined: September 6th, 2004, 10:53 am

Post Posted June 6th, 2005, 12:40 pm

Ted Mielczarek wrote:I've been meaning to make a "new extension wizard" for some time now. I should also support the chrome.manifest format. Hopefully I'll have time to do that soon.


.. would be nice :)

especially for new deer park testing .. i tried the javascript shell 1.3 though the needed enumerateWindows() was not available :/

asqueella
 
Posts: 4019
Joined: November 16th, 2003, 3:05 am
Location: Russia, Moscow

Post Posted August 17th, 2005, 10:04 am

What about this feature: when installed, EDE would register a content provider pointing to specified location (say, %ProfD%/chrome/ede, by default).

Live XUL editor and the shell are very nice, but sometimes you need to make a few files available via chrome://. Extra points for creating and registering an overlay to browser.xul.

Ted Mielczarek
 
Posts: 1269
Joined: November 5th, 2002, 7:32 am
Location: PA

Post Posted August 18th, 2005, 8:20 am

asqueella wrote:What about this feature: when installed, EDE would register a content provider pointing to specified location (say, %ProfD%/chrome/ede, by default).

Live XUL editor and the shell are very nice, but sometimes you need to make a few files available via chrome://. Extra points for creating and registering an overlay to browser.xul.


Yeah, I currently have a testbed installed. chrome://testbed/. That would be a pretty useful feature.

tagulnic
 
Posts: 1
Joined: August 18th, 2005, 10:39 am

Post Posted August 18th, 2005, 10:46 am

Hi,

I was wondering if there is a version of EDE that's compatible with Deer Park -- or a plan to build one that is.

Thanks,

-Todd

ericjung
 
Posts: 846
Joined: August 4th, 2003, 9:32 am

Post Posted August 19th, 2005, 5:50 pm

Hi,

I've been using EDE on Windows for 7 months or so. I recently switched to Xandros Linux and can't get EDE to work. I've tried it with FF 1.0.4 and 1.0.6. On 1.0.6, all I get after a FF restart is a new entry in the Tools Menu for JavaScript Console. There aren't the usual other menu items I remember from using it in Windows.

What am I doing wrong?

Thanks in advance for any help,
grimholtz

edit:: I installed EDE version 0.2.2.20050505 which appears to be the latest

niebo077
 
Posts: 1
Joined: January 13th, 2006, 5:08 pm

Post Posted January 13th, 2006, 5:11 pm

Even though I've both Winzip and Winrar installed I get the error-msg when trying to build extension? Something I've missed?

krestivo
 
Posts: 1
Joined: October 16th, 2005, 10:21 pm

Post Posted January 15th, 2006, 6:46 pm

I fixed a bug in Javascript Shell which caused any attempt to inspect any HTML window-- in fact any window other than the Javascript Shell window itself-- to blow up with NS_ERROR_XPC_BAD_OP_ON_WN_PROTO, at least on FF1.0 which is what I use.

A patch to rectify this situation is at http://www.restivo.org/projects/js-shel ... roto.patch

A similar patch needs to be applied to the props() method in shell.js, but, since I don't use the Javascript Shell (just the js-mode.el Emacs interface to the ShellServer.js), I only fixed iwhat I use. I know, selfish aren't I? Sorry about that. It might be trickier in props() because it tries to walk through the __proto__ inheritance.

What was driving me crazy is that any attempt to do an "instanceof" on a WrappedNative object would puke, blow up, go TU, freak out, and lose control of its bladder. I have no idea why. Several functions in ShellServer.js do this. Accessing .__props__ on native objects seems to have the same problem.

The patch just does catches that error and as takes it to mean, hey, thi s must be a WrappedNative object, treat it as, um, an object.

BTW Venkman seems to have the same problem AFAICT. I am making no attempt to fix it there.

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 0 guests