RFC: Extension Developer Extension

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

Post by Ted Mielczarek »

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 by asqueella »

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
Contact:

Post by Ted Mielczarek »

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 by asqueella »

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
Contact:

Post by Ted Mielczarek »

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 by asqueella »

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.
User avatar
meilon
Posts: 7
Joined: May 22nd, 2005, 6:24 am
Location: Germany
Contact:

Post by meilon »

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
Contact:

Post by Ted Mielczarek »

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

javascript shell in deer park

Post by ebricca »

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 by asqueella »

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
Contact:

Post by Ted Mielczarek »

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 by tagulnic »

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

problem on linux?

Post by ericjung »

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

Can't find zip-utility?

Post by niebo077 »

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

Fix NS_ERROR_XPC_BAD_OP_ON_WN_PROTO

Post by krestivo »

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.
Post Reply