Firefox Development
From UIDWiki
Contents |
Firefox Profiles
Firefox allows you to create multiple profiles, where each profile has different preference settings and different extensions installed. If you depend on Firefox for your regular web browsing, it's a good idea to create a special profile just for Chickenfoot development. This has two advantages. First, Chickenfoot bugs won't screw up your normal web browsing when you're not working on Chickenfoot. Second, each profile runs in a separate Firefox process, so when Firefox has to be shut down to rebuild and reinstall Chickenfoot, only the Chickenfoot profile would need to be closed, and you can keep all your other web browser windows open.
Here are the Firefox command-line options that deal with profiles:
-profilemanager starts up Firefox showing the Profile Manager
-p profilename starts up Firefox using the profile named profilename
-no-remote starts up a new Firefox process
It's a good idea to create a new shortcut to Firefox -profilemanager on your desktop or taskbar.
The install and run targets in Chickenfoot's build script now use the Chickenfoot profile when they start up Firefox. (You can change this profile name in firefox.properties.) The first time you build, the Chickenfoot profile doesn't exist, and Firefox pops up the Profile Manager instead. You should create a profile named Chickenfoot manually. Once the profile is created, the build script will use it automatically from then on, and you won't have to deal with the Profile Manager.
Running Multiple Versions or Profiles Simultaneously
You can run different versions of Firefox on your machine. This is handy if you want to try Chickenfoot on Firefox 2.0 without losing Firefox 1.5.
Even more important, you can [http://blog.dojotoolkit.org/2005/12/01/running-multiple-versions-of-firefox-side-by-side run multiple copies of Firefox simultaneously], with different profiles. Chickenfoot's build script does this automatically.
Firefox Safe Mode
If an extension is misbehaving -- e.g., if there's a conflict between Chickenfoot and another extension -- Firefox has a command-line option for starting up in safe mode with all extensions disabled, so that you can uninstall the offender.
-safe-mode starts up Firefox with all extensions temporarily disabled
Exposing Extension Functionality to Web-Page Javascript
From jstritar: I looked up how we expose an object to the javascript in web pages [in ForecastFox] - its actually really cool. The ffIWeb component provides an API for installing icon packs:
ffIWeb.idl: http://www.ensolis.com/cvs/forecastfox/src/components/ffWeb.idl?rev=1.2&content-type=text/vnd.viewcvs-markup
The key part is in the registerSelf function of gModule:
var catMgr = Components.classes["@mozilla.org/categorymanager;1"].getService(Components.interfaces.nsICategoryManager);
catMgr.addCategoryEntry("JavaScript global property", "forecastfox", CONTRACT_ID, true, true);
After doing that, the ffIWeb XPCOM object is the "forecastfox" property of the window in client javascript. The name seems to imply its a property of everything... but it doesn't seem to be. Prehaps it only applies to global objects and/or window objects. If you look at the javascript at the top of http://forecastfox.mozdev.org/packs/ source you can see how it works on that side.
Memory Leak Detection
A Firefox extension called Leak Monitor that pops up an alert dialog to warn chrome and extension developers about one particular type of leak. It warns when chrome windows close but leave native code pointing at their JavaScript objects. This typically happens for things like observers, timer callbacks, and (in Firefox 1.5 and earlier) event listeners, and is one of the most common causes of leaks in chrome and extension code. The alert shows some information about the objects that leaked (properties of objects, plus file/line for functions, which could be the object itself or properties on it). More details on its homepage, or just download it from addons.mozilla.org. It may also warn for Web pages (which is always a bug in Mozilla).
Developing XPCOM Components in C++
Creating XPCOM Components is a full book on the subject. Dates back to Mozilla 1.4 (pre-Firefox days), but the basic info is still the same.
Using Gecko SDK to Make a C++ XPCOM Component is a quick step-by-step howto with a very small sample app. Useful for getting started, but some errata:
- Change the makefile (or Visual Studio settings) so that it uses "dependent glue" rather than "standalone glue" (see XPCOM Glue for more details). This means removing the definition of the XPCOM_GLUE symbol from the makefile (or Preprocessor section of Visual Studio), and linking against the xpcom and xpcomglue_s libraries rather than the xpcomglue library .
- Ignore the part about using regxpcom. Nowadays, it's enough just to put your component's .xpt and .dll (or .so) files into Firefox's components directory, then touch .autoreg in the main Firefox install directory. When Firefox restarts, it will automatically register any unregistered components. To see if your component is being registered properly, look at the xpti.dat and compreg.dat files in the Firefox components directory (they're plain text).
- Make sure you get the appropriate version of the Gecko SDK. Gecko SDK version numbers follow the Mozilla suite's version numbers: Mozilla/Gecko 1.8 == Firefox 1.5. Also, the latest Gecko SDK isn't necessarily found in the Mozilla releases directory (ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/ ). Another source is the XULRunner releases directory (e.g. ftp://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.0.4/sdk ).
Finding xpidl.exe is a note by David Huynh about how to get xpidl.exe working, because it depends on various DLLs and IDLs that you have to dig up and point it to.
Creating Custom Firefox Extensions with the Mozilla Build System is for full-blown extensions that you want to use the Mozilla build system for.
You can debug your extension in the Microsoft Visual Studio debugger. Just specify firefox.exe as the debugging command in Project/Properties/Debugging. Ignore warnings that firefox.exe doesn't have any debugging symbols; as long as your component DLL does, you'll be able to set breakpoints and browse variables in it.
To use printf(), pass -console as a command-line argument to Firefox. The -console argument makes Firefox pop up a console window that displays stdout and stderr. You can use either stdio (C-style output, like printf) or iostream (C++-style, like cout).
Find missing header files on lxr.mozilla.org. The Gecko SDK only includes header files for frozen interfaces. Many of the interfaces you need are not frozen, so you'll have to find them yourself and drop them in your component's build directory. The safest place to find them is in the source corresponding to your release (e.g. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5.0.6/source), but if the interface is almost frozen, meaning that it isn't changing, then LXR may be a good place to look it up. LXR is easier to search, but it only has the source code of the latest trunk in the CVS repository, which as of this writing is neither Firefox 1.5 nor Firefox 2.0 -- it's (tentatively) Firefox 3.0.
If you can't get XPIDL working for translating IDL files into C++ .h files, then just use this online XPIDL service instead.
Check the dependencies of your DLL. If your XPCOM DLL depends on other DLLs that Firefox can't find, then your component will simply fail to load, with no error messages. The only symptom that the load failed is that Components.classes[] doesn't have an entry for your component, e.g. Components.classes["@uid.csail.mit.edu/ChickenSleep;1"] is undefined.
When you have this problem, try using Dependency Walker to examine your DLL and see what other DLLs it depends on, and which ones can't be resolved. Note that XPCOM.DLL and NSPR4.DLL will generally be unresolvable by DependencyWalker, but that's OK because they're part of Firefox.
Other unresolved DLLs need to be somewhere on the Windows search path (e.g., C:\Windows). For example, Kangaroo's face detector depends on CV.DLL and CVAUX.DLL, so it doesn't load unless you drop them in C:\Windows.
Another cause of DLL hell is compiling your DLL so that it relies on the C++ runtime as a DLL. You'll see it in DependencyWalker as MSVCR71.DLL or something like that. Since you compiled the DLL, you probably have this runtime in your own Windows directory, but people who have never installed Visual Studio probably don't. Change your build settings so that you link the runtime statically into your DLL, not dynamically. Then you won't have to distribution MSVCR71.DLL at all.
Reference Documentation
XULPlanet is the best reference out there for XUL elements, DOM, and XPCOM components.
Mozilla Developer Connection is Mozilla's documentation for Firefox developers.
