I'm unclear on the difference between the functioning of a plugin vs
an extension.
For years, I've written a plain old NPAPI plugin. It lived in /Library/
Plug-ins on mac and somewhere similar on a PC. With Firefox 3.6, it
stopped working. Looking around, I see this:
http://blog.mozilla.com/security/2009/11/16/component-directory-lockd...
which I figure might be the problem, so I try to turn my plugin into
an XPI, but this turns it into an extension.
I install it, and it STILL doesn't work, but now I don't know if it
doesn't work because extensions are a different beast than plugins,
and so what I did makes no sense at all, or whether it's because of
whatever the underlaying problem was before is still around, and so
what I did was a waste of time, and didn't actually address the
problem...
Can anyone give me some guidance here?
thanks.
The answer is "it's because of whatever the underlaying problem was before is still around". The lockdown post clearly states that you'll have problems only if you put your files inside Firefox.app/.../components (if you mentioned this link in your original post, you wouldn't have to try and make it into XPI).
The relationship between extensions and plugins is: an extension may include plugin(s), among other things. You can install plugins (without making them into an extension) in Firefox.
As for your original problem, unfortunately I have no idea why it doesn't work. I'm not well-versed with debugging NPAPI plugins and the only bit of information you shared is that it doesn't work in Firefox 3.6 :)
As a first step, does it appear in about:plugins or in Tools -> Addons?
You can install a plugin as part of an extension (optionally using an XPI) if you want.
The reason that your plugin stopped working in Firefox 3.6 is almost definitely that Firefox 3.6 stopped supporting the XPCOM method of providing a scripting interface. Most likely, your plugin loads but you can't talk to it in javascript.
For more information, look here: http://colonelpanic.net/2010/01/firefox-3-6-has-removed-support-for-xpcom-plugins/
Also, if you need to update it, you might consider using FireBreath, which extracts a lot of that complexity away from you.
Related
I am porting over a Chrome plugin to Firefox as a Webextension. I have gotten almost all the way through my rather large codebase and switched things that were incompatible, however a management.onInstalled and .onUninstalled, onEnabled and onDisabled are the last few functions I can't seem to find a Firefox equivalent for. Any suggestions?
These events are not currently implemented in Firefox. If you have a compelling use case for them you can add a comment at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1282984
When I’m programming a Web app and I run into a problem that only seems to happen in one browser, I know that a somewhat-essential step among my overall programming tasks as a “good citizen” is to stop coding for a bit and take time to report the bug in the right place—so it can get fixed and other Web developers (including me) hopefully won’t run into the same problem later.
In such cases with Firefox, I understand enough to know when the cause of the programming problem I’m seeing is in the core “Gecko” browser-engine code in Firefox (rather than instead being, say, a bug in the Firefox user-interface code—the code for the so-called browser “chrome”).
Given that, is there a URL that will take me directly the form where I can quickly get to the right bugzilla “product” and “component” to report a Gecko browser-engine bug against?
Having already reported a few bugs in the Gecko code, I am somewhat annoyed at being forced to use the form at https://bugzilla.mozilla.org/enter_bug.cgi, which seems to assume I’m reporting a bug for the first time and I want guided step-by-step help. But this ain’t my first barbecue…
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=default is the URL you want.
That’s because in the case of Firefox, the right bugzilla “product” to use for browser-engine (Gecko) bugs is actually Core (not the Firefox component—and there is no Gecko component).
That URL above takes you directly to an actual bug-reporting page—that is, as you’d want, it completely skips all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
You do need to then manually choose the right “component” from the Component list there, but if you already know the right component, you can make a bookmark that includes it; e.g., https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Workers&format=default is a URL that will let you report problems with Firefox Web-Workers behavior.
Adding the &format=__default__ parameter/value is the important part needed to get bugzilla to skip all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
I have the source code from a plugin for second life to play in a browser but the problem is it's been created for Firefox 3.5, so what I'm trying to do is to bring it up to speed and upgrade it to the current Firefox.
Unfortunately I'm not sure how to go about this as I am literally just looking into this now, any help is greatly appreciated
What's your main aim here? Are you interested in simply making the extension work somehow in the latest firefox or are you more interested in optimizing performance?
Optimization of an application is a very general topic. You can look into the upgrades Gecko has gone through in the recent versions. If there seems to be any specific module for which Gecko is now offering a better interface/compatibility, you might try adapting the same. Again, this is really the programmer's judgment and skill which lets him draw the boundary between feasible and non-feasible development. For a module which is extensively linked with many other modules, it might be a good idea to leave it as it is to avoid sleepless nights (of course that's just my opinion. For some, that is the real kick :D).
If you are interested in creating high-performance plugins, you might like to give Google Web Toolkit a try. It is a Java library which compiles java into optimized javascript introducing various performance oriented quirks. I understand that it is not possible to switch an entire application to GWT easily and wouldn't help you just now, but I think it is worth mentioning for future use.
On the other hand, if you are just interested in making the extension work, you may look into Nightly Tester Tools, which is an extension used to override add on compatibility.
I've just recently downloaded vsVim to use it with Visual Studio 2010 and join the Vi way. But I haven't been able to find information regarding the specific vsVim documentation.
I know how to use Vim (basic use, nothing even intermediate) but I would like to know if there is something that is still missing from the vsVim implementation, or some special feature.
So could anyone point me to a good resource about vsVim?
Thanks for any help
Jared has said that the git issue list is the main place he tracks feature requests and issues - so having a look at requests should give you an idea of what notable features are missing.
There is a Wiki, which explains things such as (intended) nonstandard behavior. Also, watching the GitHub repository is a good way to learn both what is and isn't implemented in VsVim and also to learn Vim features that you didn't know about. I've certainly learned a number of things about Vim from feature requests that are posted there, etc.
There are many things missing from the VsVim implementation, and there always will be. There are just certain areas of Visual Studio that you can't accurately layer Vim on top of (for example, the mismatch between the way Visual Studio handles documents, windows and tabs and the way that Vim handles buffers, windows and tabs). However, more and more is supported continuously, and you can always submit a pull request. Jared is very friendly and good to work with. I started using VsVim a year and a half ago and already much more is supported then when I started using it.
If you are wondering whether you are doing somethign wrong or whether it just isn't implemented in VsVim, a good thing to do is to pop open Vim and use its :help feature to find out. You can always submit an issue on GitHub, or if you really want to learn Vim in a detailed way, you could work on implementing a feature.
Finally, the documentation is incomplete, but since it is a wiki, you are welcome to contribute to it as you learn.
I want some personally developed JavaScript code to execute whenever I load a page in Safari. Seems like addblock for Safari does this. Anyone know how to do this?
Safari is not extensible. There's no addon framework for it. But yet there's adblock and verious other addons available for it, although Apple's Webkit and Safari developers discourage users from using them, calling them 'binary hacks'. Seems though some of these addons use InputManager, which isn't documented at all anywhere, at least for not for how people are using it to load scripts in Safari. I guess I'm going to have to backwards engineer to see how addblock does it, but before I do, I thought I'd ask around here. Anyone know?
Input managers are a commonly (ab)used way of injecting arbitrary code into another application's runtime. Once you are there, you have to reverse-engineer enough of the application itself to figure out how to get the behavior you want; usually that involves method swizzling to replace parts of the application you are hacking. It's not documented because there's no API to document, but you can learn about the individual pieces (how to write an input manager in general, how method swizzling in Objective C works, how to use tools like class-dump) and then put it all together.
What you are describing sounds like Greasemonkey though, and there are least one or two hacks already out there to enable Greasemonkey-like behavior in Safari. I'd suggest seeing if one of them meets your needs first.