Closed Bug 41274 (vbscript) Opened 25 years ago Closed 13 years ago

Add VBScript engine for Mozilla

Categories

(Core :: General, enhancement)

Product:
Core
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: zuperdee, Unassigned)

References

Details

(Keywords: helpwanted)

This bug is kind of a spin-off of 40952. Basically, it would be interesting if Mozilla supported other scripting languages besides JavaScript, like VBScript. Not essential, I'll agree, but it would be interesting.
Hmm... Now if only someone could come up with a VBScript engine, is it possible for it to be plugged into Mozilla the same way JavaScript is?
Keywords: helpwanted
*** Bug 47161 has been marked as a duplicate of this bug. ***
It has just occurred to me that GNOME Basic claims to be Visual Basic compatible. Therefore, that may be a good base to start from, if one wanted to start making an open source VBScript engine for Mozilla. Hmm... Anyone?
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Future
leger is no longer @netscape. changing qa contact to component's default
QA Contact: leger → chofmann
*** Bug 146690 has been marked as a duplicate of this bug. ***
The link for GNOME Basic is http://www.gnome.org/projects/gb/ if anyone is interested. As I say, this might be a good starting point for creating a Visual Basic engine that could be plugged into Mozilla. Also, I am beginning to think there may be far more of a market for this feature today than there was at the time I filed this, since 1) There are a growing number of sites (other than Microsoft) using VBScript today, like the one cited in bug 146690, and 2) the ".NET initiative" is rapidly gaining traction (of which VBScript is one component, as I understand it). Therefore, I'd now *REALLY* like to see this implemented.
VBScript is unhealthy.
Component: Tracking → Browser-General
Brendan, in the unlikely event that someone were to produce a patch that would add support for VBScript, would it be accepted or rejected? (IOW, WONTFIX or not?)
Whiteboard: Propose WONTFIX
*** Bug 153668 has been marked as a duplicate of this bug. ***
Maybe Moz could just use Windows' built-in vbscript engine?
as with most mozilla rfes, we prefer cross platform implementations (see also NTLM). This bug is filed for a cross platform implementation, so if you want to file or find a bug to add support for windows activescripting you are free to use it to develop a patch. As for Gnome Script, that's GPL so i don't think we can realistically use it for a while.
Hmm... Any chance of talking to the GNOME Basic author, and asking if he'd be willing to dual-license it under the MPL and GPL? Would that help? Just a thought...
In that case I suggest changing the title to "Add cross-platform VBScript engine for Mozilla".
Is someone working on this?
Alias: vbscript
Summary: VBScript support would be neat to have! → Add VBScript engine for Mozilla
Whiteboard: Propose WONTFIX
AFAICT, there would be at least two general issues here. 1. We'd need an engine (XP or otherwise). 2. We'd need to start handling language="vbscript". That would require accepting said language tag *and* handling the language itself; the latter part seems to be the hardest part.?
Yeah, the content code is not set up to handle new scripting language types smoothly. Cc'ing jst. I expected the ActiveState guys to make Python work, but they never needed it -- they only needed PyXPCOM (the Python "XPConnect"). /be
Once we have a VBScript engine, making the content code do the right thing with language="vbscript" should be trivial.
jst: really? Don't we need to have multiple nsIScriptContexts, one for each language type, per window? And nsIScriptGlobalObject{,Owner}s? Don't we need some extra layer of dispatching and multiplicity to cope with event handlers written in VBScript as well as those written in JS? Etc. /be
How about nsDOMClassInfo?
Eh, yeah, sure. There's a lot to this, but I was specifically refering to the content code that deals with figuring out what language a script is in, that part should be trivial. But there's obviously a lot of work to be done to integrate the engine itself into mozilla. Did someone say VBConnect? Eh, hmm... :-) I don't know how much quirkyness there is in VBScript when run in IE, so we may or may not need much hacking in nsDOMClassInfo. I guess I don't know enough about VBScript to say, nor do I know how IE's DOM is exposed to VBScript either... But having said that, it seems like in comparison to writing the VBScript engine, hooking it into Mozilla should be fairly easy once we have an engine.
If you want an Win32 only VBScript engine, then why not use the IE one? There are APIs in the form of IActiveScript & IActiveScriptSite through which you can instantiate and control it.
http://www.newwindenergy.com/regional/mid-atlantic/buywind.asp is currently VBScript and since Mozilla can't do it (sometimes??) this is preventing me from signing up to get wind power for my electricity source! For those who want to use microsoft tools - please forget it. I'm on a Mac and don't have those. Nor do I on any other unix os.
Blocks: winupdate
Marked 28321 (Adding windowsupdate support) as being blocked by this.
Status: NEW → ASSIGNED
Is anyone working on this. There are quite a lot of pages today that use VBScript and it would really be nice to see Mozilla support it.
>Is anyone working on this. No
Assuming someone added plumbing such that any ActiveScript engine could be plugged into Mozilla, then yes VBScript (and JScript, PerlScript etc.) could be supported, at least on Win32. Other than that, no one to my knowledge is working on support, primarily because VBScript is a junk language and proprietary to boot. Implementing it would allow Moz to render more pages, but the significant effort required would be high and payoff would be small since many VBscript sites still wouldn't work because they rely on other proprietary features such as ActiveX. Of course if there was a ready to use open source VBScript impl out there, then it should at least be considered. Does anyone know if there is?
So interesting, but it couldn't be include in Moz 1.4 final, at least.
Well, I just wrote to the GNOME Basic author, and here's what he said: ------------------------------------ Hi Daniel, On Sat, 2003-09-20 at 07:44, Daniel wrote: > You say GNOME Basic can do VBScript? Is there any > chance of GNOME Basic being a cross-platform VBScript > solution? Absolutely non at all :-) Gnome Basic is completely dead - however it's not all bad news; some of the code, and most of the contributors live on in the Mono project: http://www.go-mono.com/ which already has a better VB.Net implementation, a beautiful JIT etc. etc. > The Mozilla bug I speak of is found here: > http://bugzilla.mozilla.org/show_bug.cgi?id=41274 Interesting. Of course - the only hope is if you are prepared to do the work yourself; I'd join the mono mailing list and see if anyone is going to help you learn to hack mono into what you want. Regards, Michael. ------------------------------------ I have no idea how the licensing of Mono would fit into it, but it *IS* cross-platform, according to: http://www.go-mono.com/faq.html#portability Here is how it is licensed: http://www.go-mono.com/faq.html#licensing
*** Bug 241462 has been marked as a duplicate of this bug. ***
Depends on: dom-agnostic
Perhaps a VBScript to JavaScript translator would be better than building a VBScript Engine? This would avoid duplicating a lot of things that the JS Engine team has already done. Then if Mozilla sees any vbscript it could just replace it with corresponding JavaScript before it is run?
I really don't care about this bug, except that if someone is motivated to help prove the new APIs being developed to fix bug 255942, by using them to embed some optional VBScript extension that isn't any more broken than the one available in IE, then that would *probably* be helpful test the new APIs. But it might just be one too many cases to support at once, or a case that we never care about but that has its own hard edges that cost us. The explicit goal of bug 255942 is to support <script type="application/x-python"> in XUL only, with some support for TCL looking likely to come along for the ride. Since this bug remains assigned to nobody, helpwanted, Future, I wouldn't sweat the details of how it should be fixed. /be
No matter what hosting APIs we come up with, they are unlikely to mesh well with the existing WSH engines. I don't think compatibility is going to be a goal (or necessarily should be). Those hookups are old, crufty, and very historical to handle a lot of edge cases and backwards compat. If somebody someday decides to try this, expect to wander far into the world of undocumented Windows interfaces. On the other hand, that's still probably easier than trying to put together a new engine for this language.
Product: Browser → Seamonkey
Assignee: nobody → general
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: chofmann → general
I have a question, If this is ever implimented (which looks doubtful unless someone is willing to work on it), won't using an existing Windows interface limit compatability with Linux and Mac? I know it was never designed to work on Linux and Mac but if its own engine was buit within Gecko, would it have compatability with Linux and Mac?
I did see some recent articles that Microsoft is slowly starting to do less with the ActiveX while replacing a few of them with a non-ActiveX stuffs. Thought that was interesting but that DOESN'T mean it is what will happen to all of them in the foreseen future.
Assignee: general → nobody
Product: Mozilla Application Suite → Core
QA Contact: general → general
*** Bug 349302 has been marked as a duplicate of this bug. ***
*** Bug 362280 has been marked as a duplicate of this bug. ***
On the Windows side, VBScript makes it very easy to use WMI Classes making it very useful. For instance I need to update 65 computers to use a new database configuration at work. Using VBScript and WMI Classes from Explorer I can update the computers remotely. I can also craete a web page that lists all the computers in active directory etc.. Paul
VBScript is pretty much dead now as it had crossed-over to VB .NET. You can alway use the .NET framework for that.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.