RFC: Extension Developer Extension
-
- Posts: 1269
- Joined: November 5th, 2002, 7:32 am
- Location: PA
- Contact:
-
- Posts: 4019
- Joined: November 16th, 2003, 3:05 am
- Location: Russia, Moscow
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.
I can make prefs window if you like.
I don't get the point of JS Injector.
-
- Posts: 1269
- Joined: November 5th, 2002, 7:32 am
- Location: PA
- Contact:
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.
-
- Posts: 1269
- Joined: November 5th, 2002, 7:32 am
- Location: PA
- Contact:
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.
- meilon
- Posts: 7
- Joined: May 22nd, 2005, 6:24 am
- Location: Germany
- Contact:
Hiho,
i have just started in developing extensions for my FireFox. *Thumbs Up* for your super extension
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
i have just started in developing extensions for my FireFox. *Thumbs Up* for your super extension
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
-
- Posts: 1269
- Joined: November 5th, 2002, 7:32 am
- Location: PA
- Contact:
-
- Posts: 3
- Joined: September 6th, 2004, 10:53 am
javascript shell in deer park
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 :/
-
- Posts: 4019
- Joined: November 16th, 2003, 3:05 am
- Location: Russia, Moscow
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.
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.
-
- Posts: 1269
- Joined: November 5th, 2002, 7:32 am
- Location: PA
- Contact:
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.
-
- Posts: 846
- Joined: August 4th, 2003, 9:32 am
problem on linux?
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
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
-
- Posts: 1
- Joined: January 13th, 2006, 5:08 pm
Can't find zip-utility?
Even though I've both Winzip and Winrar installed I get the error-msg when trying to build extension? Something I've missed?
-
- Posts: 1
- Joined: October 16th, 2005, 10:21 pm
Fix NS_ERROR_XPC_BAD_OP_ON_WN_PROTO
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.
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.