Making your add-on compatible with Firefox 4

Firefox 4 beta 7 is out, and now is the best time to evaluate your add-on’s compatibility with the next major Firefox release. This is the first “feature frozen” release, meaning that there will be no more major changes performed to the UI, APIs or features in Firefox. Other than bug fixes and stability improvements, this the Firefox that will make it to the public, and you should be able to upgrade your add-on to work for this beta without having to worry about something being broken in the following betas and release candidates. Firefox 4 is coming! If you want your add-on to be compatible, the time is now.

How can you keep track of releases? One way is to download the latest beta and check for updates regularly. New versions are normally being released every few weeks. You can also visit the Releases page regularly. Finally, you can follow the Mozilla blog and keep up with Firefox news.

In this blog post I’m going to cover all breaking changes introduced in Firefox 4 that I’m aware of, including the ones I mentioned on my previous 2 posts (Part 1, Part 2). Firefox 4 is the largest release so far in terms of code and API changes, so there’s likely something on this list that affects your add-ons. This list is as thorough as I could manage to make; my objective is to make it as easy as possible for you to update your add-on so your users won’t have a hard time deciding if they should update their Firefox or not.

Add-on Packaging and Development Environment

In order to improve Firefox performance, a lot of work is being done to improve file loading and processing at startup. This includes add-on files as well, so there are a couple of changes that concern us.

Packed extensions

Firefox 4 will ship with most code files packaged in a single JAR file, also referred to as Omnijar. Reading files from a package is generally much more efficient than reading them independently from the filesystem, so keeping as many files as possible packaged together is a performance win, specially on mobile platforms. The same idea is now extended to add-ons, and by default they will be installed in the profile folder without unpacking them. There are some consequences to this:

  1. Some add-ons will not work without unpacking, notably add-ons with binary components or other libraries. This also affects dictionaries and add-ons that include search plugins or window icons. Those add-ons that need to be unpacked must add an unpack flag to their install.rdf manifest.
  2. If you read any files that are contained in your XPI from the profile dir, this won’t work anymore. You can extract them using the chrome protocol or the nsIZipReader component, or find other ways to generate them. You can also use the unpack flag if nothing else works.
  3. You can still have you working directory in your profile as you did before. The extension loader will check for either the XPI package or the unpacked directory. However, for the final build you should aim to have your add-on installed without unpacking.
  4. It’s also recommended that you move away from the previously recommended practice of packaging all chrome files in a JAR. Since the XPI is not unpacked anymore, having the JAR (a package within a package) only adds overhead.


Firefox is now caching code and other resources more aggressively. To make sure that your development profile is always picking up the changes, you should run Firefox 4 with the -purgecaches command line option. This will clear all relevant caches, to make sure you’re running the latest code.

The Profile Manager

The Profile Manager tool we’ve grown accustomed to is being taken out of Firefox. There’s a long discussion surrounding the reasoning behind this decision. In a nutshell, the profile manager hasn’t been updated for a very long time and is lacking in features, on top of some of its code causing slowdowns at startup. Needless to say, it won’t be removed without a suitable replacement. Bug 539524 is tracking this new development. The new tool will work independently from Firefox, kind of like a launcher script, and is meant to be more robust than its predecessor. Since this tool is not bound to the Firefox 4 release timeline, it could be finished after Firefox 4. You can always use the Firefox 3.6 Profile Manager in the meantime, of course.

Global extension installation

The -install-global-extension and -install-global-theme command line options have been removed. Global installation has always been a tricky subject, but there will surely be discussions in the future on how to move this forward while respecting users. For alternatives on how to automatically install add-ons, read this documentation at MDC.


XPCOM Registration

Components now need to be explicitly declared in the chrome.manifest file. This includes binary components as well. A number of startup observer topics have been removed, leaving only one: profile-after-change. Listeners and category registrations also need to be declared in the manifest and, because of this, some category names have changed. More details at MDC: XPCOM Changes in Gecko 2.0.


xpcnativewrappers=no is going away. This practice has always been considered unsafe, and there are safer alternatives for it.

The new Gecko SDK is still not available at the MDC page. Developers that use binary XPCOM have to build it themselves from source. The source code for beta releases is available at the FTP site.

The old and deprecated nsIPref interface has been removed. This shouldn’t affect anybody using the recommended nsIPrefService or the FUEL library.



Toolbar buttons have different dimensions. Here are the current icon sets for the major platforms:

  • Windows. Icons are 18 x 18 px. They have a very simple style and appear to be same for Aero and non-Aero.
  • Mac OS X. Icons are 20 x 20 px. Simple style as usual, but this time around the icons don’t include the surrounding button style, making them more consistent with other platforms.
  • Linux. Icons are 24 x 24 px. As usual, the theme relies mostly on Gnome icons.

This is a radical departure from the 3.6 icons. Only Linux retains the same icons and icon sizes, so you’ll need to create new toolbar icons for Firefox 4 unless you want to deal with scaling (you don’t). Fortunately, the chrome manifest file allows you use some convenient flags that allow you to easily separate skins depending on OS and application versions.

Also, if your add-on creates a new toolbar with an overlay, you may find that your toolbar is not showing up. This happens when your toolbox element overlay is a child of the window element, instead of a direct child of the overlay element. Moving the node out fixes the problem.

The Firefox App Menu

The main menu (File, Edit, View, etc.) is now hidden by default for Firefox 4 on Windows. Instead, there’s a single button that opens a simplified Firefox App Menu. This menu includes the most used menu features, making users’ lives easier. The “classic” menu can still be toggled using the Alt key.

If your add-on is only discoverable through the main menu, you’ll want to overlay the app menu as well. There’s no exclusive spot for extension menu items, so you should study the menu and identify the best one for yours, and then find the right ids for your overlay.

The Statusbar

It’s gone. It has been replaced with the Add-on Bar.

By default, there will be no more chrome at the bottom of the browser window. If an add-on adds an icon or something else to the Add-on Bar, it will appear in the same location and with a similar style as the current statusbar. The Add-on Bar has the advantage that it is a proper toolbar, and it may allow user customization in the future (but not in Firefox 4?). It has the disadvantage of being turned off by default, and also being thicker, meaning that users will not be very welcoming of add-ons that add stuff down there.

For backward compatibility, the old statusbar is now completely contained in the Add-on Bar. So, if your add-on overlays the statusbar, it will continue to work. This is only a transitory solution, so you should look into moving your buttons out of the statusbar and into the Add-on Bar as soon as possible.


Beta 4 shipped with a new feature called Firefox Panorama (formerly known as Tab Candy). This is a major new feature and a new way to look at and manage tabs in Firefox. Unfortunately this also means that some tab manager add-ons may break due to the changes introduced in the Firefox tab code. There’s a new button in the tab bar that triggers Panorama, and also a tab context menu option.

Tabs appear on top by default. There is a preference that controls the location of the tab strip and toolbars.

App tabs. It is now possible to toggle tabs into app tabs, which basically means they can’t be easily closed and their titles are hidden, only showing the favicon.

The Add-on Manager

Firefox 4 has an overhauled Add-on Manager, no longer opening as a separate window but as a new tab. There’s much more room for add-on information, and the space for your add-on icon is now 64 x 64 px. The old 32 x 32 px icons still look OK (they are not scaled), but you’ll probably want to upgrade. Scaling down to 32 x 32 is not too bad, so you can include the larger icon without having to worry too much about backward compatibility.

The Add-on Manager backend was also overhauled. The nsIExtensionManager interface is no more, along with its RDF storage. Add-on metadata is now stored in a SQLite database, and the Add-on Manager is now a JS Module named AddonManager. A key difference in this new interface is that requesting add-on metadata is asynchronous. This applies to the FUEL library as well, so every add-on that requests add-on data is affected. This is particularly delicate for add-ons that have to fetch and deal with this data at startup. However, if you’re also trying to follow our startup performance recommendations, you should already be planning on implementing an asynchronous startup process anyway.

XUL and Overlays

The DOM surrounding the tabs and their internal browser elements has changed to allow easier overlaying. However, this means that if your code browses the DOM using parentNode, like to get access to the associated notificationbox of a tab, you may find that this code no longer works. This is something you shouldn’t be doing anyway, since the gBrowser object and its related objects have convenient methods to access these nodes.

The TabClose, TabSelect and TabOpen events no longer bubble up to the tabbrowser element, also known as gBrowser. Event listeners for these events should be added to gBrowser.tabContainer.

Remote XUL

Remote XUL is a rarely used feature in Gecko browsers that allow developers to create websites using XUL and XBL instead of (or along with) HTML. Since XUL support is limited to a few browsers, it never made much sense to create websites with it. However, it has been used successfully on a number of internal business applications (also known as “XUL dark matter”), and even some public websites.

Remote XUL has been a big maintenance problem, and has been the source for numerous bugs and security problems. For this, remote XUL will be removed in Firefox 4. Luckily, HTML 5 already includes a fairly robust box model, so the main loss here is that web developers will not be able to use XBL on webpages anymore. This also means that inserting XUL into (remote) HTML pages will not be possible anymore, not even for add-ons in some cases. If the code is loaded from a chrome URL, like in an iframe or an XBL binding, this should continue to work.

In a nutshell, XUL content from remote sites of even the local file:// protocol won’t load. Not all is lost, however. To enable a transition period from XUL to something else, remote XUL support hasn’t been entirely removed, only disabled. There’s a whitelist where individual domains can be added in order to enable XUL and XBL on them. This whitelist is not accessible from the UI, though, so I’ve created the Remote XUL Manager add-on to fill this gap. You should be able to easily manage the whitelist with this add-on.


  • JS objects can no longer be passed between threads, making the Thread Manager object fairly useless for add-on developers. This is a last minute fix that will hopefully affect just a few developers, but it will have a high impact because there are few alternatives available at the moment. There are discussions about improving the ChromeWorker interface so that it becomes a suitable replacement, but it remains to be seen if this will happen in the coming betas.
  • User Agent strings have been minimized for privacy reasons. In order to align with these efforts, AMO Editors will be looking for UA manipulation in extensions. We will forbid any unnecessary modifications. Unless your add-on really needs to change the UA, you should remove this code.
  • There’s one bug that affects theme developers on Windows, and causes a black box to appear near the titlebar. There are a few workarounds explained in this Mozillazine thread.
  • JSON Strings with trailing commas are no longer accepted by the SpiderMonkey JSON parser.
  • The network redirects API has changed to be asynchronous now. This affects any extension registering in the “net-channel-event-sinks” category, breaking all redirects.
  • Dropping a URL into the sidebar now has the default behavior of trying to open this URL. If you handle drag and drop in your sidebar, make sure you use preventDefault.
  • Firefox 4 will support the 32 and 64-bit Intel architectures on Mac, and has dropped PPC support. List of supported platforms.

Documentation and Help

We’re trying to publish as much documentation about Firefox 4 as possible in order to help add-on developers get everything right the first time. The Firefox 4 for Developers article is the official source for everything that’s new in Firefox 4, including breaking API changes. There are, however, many things included in this post that are not included in the article. I tried to cover everything I’m aware of, and if anything else changes or is discovered during the release process, it will be documented in this blog.

If there’s anything you think I’ve overlooked, or you want to discuss about Firefox 4 compatibility, this thread in the Add-ons Forum is the best place to go. You can also join our #extdev IRC channel for one-on-one live help. I usually hang out on that channel, but there are also lots of other experienced developers willing to help. Just join the channel and ask your question.

Finally, if you have a featured add-on, or you want your add-on to qualify to be featured on AMO, you should take into consideration that after Firefox 4 RC1 is released, add-ons must be compatible with the latest release in order to qualify. RC1 is scheduled for January 2011, so make your plans accordingly.

Happy coding!

44 comments on “Making your add-on compatible with Firefox 4”

  1. Justin Dolske wrote on

    I don’t see why the Profile Manager is listed here — nothing is changing for Firefox 4, it will continue to be available and work just as it did in Firefox 3.6.

    Yes, there are plans to eventually do something with it _after_ Firefox 4, but it’s confusing to bring that up in a post that’s specifically about Firefox 4.

    1. Jorge wrote on

      Do you have a reference for this, Justin? All I have read about it points to a bug that already has a patch. It’s not flagged as blocking 4.0, but I wouldn’t be too surprised if the fix is pushed in the coming months.

  2. Nils Maier wrote on

    The icon size changes are actually more complex, as there are more places users might add toolbar buttons, and each place potentially expects different icon dimensions:
    * Regular toolbar (navbar)
    * Regular toolbar, but configured to use small icons
    * The Tab-bar (Might want to consider a monochrome icon there): Better use monochrome icons there
    * The AddonBar (Status bar replacement): Might be a good idea to drop the toolbarbutton borders
    * Bookmarks bar: Again, other items are displayed without borders
    * Other customizable third-party toolbars

    You can of course still build platform-specific stylesheets and provide different rules depending on where your toolbar button is displayed.

    #my-button { … }
    toolbar[iconsize=”small”] #my-button { … }
    #nav-bar > #my-button { … } /* usual toolbar */
    #TabsToolbar > #my-button { … }
    #addon-bar > #my-button { … }
    #PersonalToolbar > #my-button { … } /* bookmarks */

    If you don’t feel like creating x different resolutions of your icons and ship that (increases download sizes, too) you might go with the not-so-pixel-perfect solution of allowing the application to scale your icons.
    For raster images the scaled result usually looks *very* bad, as the edges get very blurry.
    But SVG images are supported to be used almost everywhere incl. CSS list-style-image in Firefox 4, so you might consider using those. The scaled result usually looks far better than scaled raster images.
    Hint: make sure your SVG uses viewBox’ing instead of absolute width and height. Latter would crop the SVG image instead of scaling it.

    PS: Loading window icons from everywhere is currently tracked in:

  3. Jay wrote on

    For the new Toolbar icons, do you have examples, or instructions on how to make ours look and conform more with Firefox’s new default?

    Alternatively, the original photoshop files for, etc would help too.

    1. Jorge wrote on

      I think I’ll be posting a new article focusing exclusively on icons and how to make them work on Firefox 4 on all major platforms. It’s a tricky enough subject to warrant separate attention.

      1. edwink / feedly wrote on

        Part of the challenge for toolbar icons is to be able to have one xpi which can be installed on both firefox 3.x and firefox 4.x and be able to specific two different set of icons (given that the toolbar styles are so different). Is there an easy way to do that? Is there a way to us the firefox version in the CSS selector?

        1. Jorge wrote on

          This is better handled at the manifest level, rather than the CSS level. So, I recommend, that if you need different rules for 3.x and 4.x, that you create 2 sets of styles and then define which ones will be applied on the chrome.manifest, where you have access to version and platform flags.

  4. Tony Mechelynck wrote on

    Much of what is being described here (but not all of it) are of course in fact “Gecko 2” changes not specific to Firefox, and as such I would recommend this article even to authors of mailnews (or other) extensions meant for Thunderbird 3.3 or SeaMonkey 2.1. In particular the “unpacked XPI” “XPCOM registration” “no remote XUL” and “new addons manager” changes are Gecko 2 changes applicable all over the board.

  5. Steven wrote on

    In general I think FF4 is going the right way. Unfortunatly, all the changes need to be documented and the examples have to be implemented or getting an update. At least you should focus on examples to replace no longer working examples. For examples the toolbarpalette is broken/changed/bugged? The example from the tutorials is no longer working in FF4 and it is unclear how to get custom toolbarbutton to the toolbarpalette. Especially when there is no status bar visible by default, and under Windows the menubar not visible as well. Hope this is getting fixed soon, otherwise I already see a lot of fixed toolbarbutton getting on top.

  6. Michael Kaply wrote on

    The icon situation is just stupid. There is really no other word for it.

    The Firefox designers continue to show complete disregard for add-on authors.

    It’s getting a little old.

    In addition, bugs I’ve opened to discuss the different problems simply get ignored.

  7. johnjbarton wrote on

    “The Add-on Bar… has the disadvantage of being turned off by default, and also being thicker, meaning that users will not be very welcoming of add-ons that add stuff down there.”

    Yeah. That’s great. Hide it, make it crappy, maybe we’ll go away.

  8. Jerella Franklin wrote on

    I love all the new tool bars we can add on but my back and forward button disappeared. I miss my back button alot, please return it. LOL I also wish there was some way it would be possible to stop hackers from invading our computers while playing games on face book. I know some of you computer geniuses could figure something out.

  9. Richard wrote on

    I’m giving up on Firefox 4 – have been running the betas all along, and with this latest beta release IT SUCKS SO BAD I WILL NEVER USE IT.
    HATE HATE HATE the most recent changes to the UI – BIG BIG BIG steps backwards including –
    the remember password dialog is now a popup again that can be lost before you know if you entered the right password

    eliminating the status bar breaks all kinds of add-ins and functionality – one of the most serious being not being able to see url’s accessed during a page load (especially when server is down and page not loading – no longer can see where it is hanging), and can’t view hyperlinks when you mouse-over (the functionality of it appearing in awesome bar is not at all reliable esp when on secure sites)

    Many addons that worked prior to Beta7 no longer work.

    Sorry, but I’m done with FF4. 4ever.

    1. Anonymous wrote on

      I use the Fission extension for the status bar problems. Fission puts the outgoing links into the address bar when hovered, along with the loading status up there, too. Firefox 4 will need something similar, already built in, to see all of that information. Actually, I don’t see why every browser doesn’t just do this.

  10. Reivax wrote on

    Thanks for breaking the thread manager without notice, without replacement and without documentation, all this between two betas.

    I almost can’t believe this happened.

    You just leave developers with no alternative.
    With every release, development of Chrome extensions tastes better.

    1. Anonymous wrote on

      I love Firefox, but Chrome extensions are SO much easier to code. They’re just miniature web pages that you can test without packing and restarting! I’m done with the confusion of Firefox.

  11. Sandy wrote on

    Anyone know would the broken toolbarpalette in beta 7 be fixed soon? It breaks my extension on Mac and Linux… I agree it is a torture to make things compatible with FF4

  12. ondras wrote on

    Thread manager gone?

    My addon cannot live without concurrency and Workers cannot be used, since I pass complex JS objects (with methods etc) between threads.

    Great! :-(((

  13. Cobra wrote on

    “The Statusbar – It’s gone.”
    So is my interest in using Firefox 4… Also, most probably I will not update my extension, since the only UI element it adds is (was) in the statusbar.

    I think that Firefox 5 will look like this:
    No address bar, no navigation bar, and generally none of these useless, outdated things; instead, five huge, shiny icons:
    A) Open FaceBook
    B) Open Gmail
    C) Open YouTube
    D) Activate pr0n-mode
    E) Open Redtube

  14. Make everything configurable…an option for THE USER not THE DEVS wrote on

    OMG, why do Firefox Devs keep removing/merging crap??? I like my statusbar!

    Sure, I’ll check out Firefox 4 with it’s statusbar-less-ness…but really, WHY did they just outright REMOVE it? Can’t they…

    1. Turn it off & make it a checkbox pref
    2. Scrape the statusbar code into an Addon & release that
    3. Turn it off & make it an about:config hidden pref

    …I mean, at least lemme turn the damn thing back on!!!

    I don’t think I’m gonna like that bloated “Addon bar”, unless I can make it thin like the statusbar.

    Why can’t they just remove the “special statusbar” (that wasn’t a “real toolbar”) & make a “status panel” toolbar item, then we could put the “status panel” item on the “Addon bar” (or any other toolbar) & get our “statusbar” back?!?

    I think someone needs to make an Addon…or series of Addons…called “Firefox Unfucked”…like “Firefox Unfucked: Re-add Statusbar”, “Firefox Unfucked: Unmerge Search & Location bar”, “Firefox Unfucked: Unmerge Back & Forward buttons” (“NoUn Buttons” does this, but it’s just an example)…I need Addons to undo all the crap they are doing to Firefox!

    Firefox Devs: STOP REMOVING/MERGING EVERYTHING…at LEAST move the code to an Addon, so we can UNDO whatever you are doing. The code is there to do what we want, just move it to an Addon (not remove it completely) & let us install it if we want it back. Make every feature an Addon, install some by default, remove others, then we can ALWAYS get them back if we want them.

  15. Ben Bucksch wrote on

    > so you’ll need to create new toolbar icons for Firefox 4

    Sorry, but that’s a complete no-go. Creating icons is expensive, it involves art departments. It’s also continuous cost to maintain 3 sets of icons.

    Please fix this. There must be one icon for all situations and places and platforms. I don’t care whether it’s 24x64px or 64x64px. Even SVG might work (although that’s considerably more work, too). What does not work in practice is 3 entire sets.

    Please fix this. This is a *must-fix* for FF4.0, you *cannot* ask *all* extentions to change *all* icons, just because you feel like it. You may theme as you like, that’s the idea, but it must not have effects on other code, esp. third-parties like extensions, that’s *also* the idea of themes.

    1. Anonymous wrote on

      Chrome extensions use one 128×128 image, which is then automatically resized according to different purposes (tab icons, buttons, etc.). I no longer consider Firefox to be anywhere near efficient. It’s too bad. They had a good run, though!

  16. Alfonso wrote on

    Asking for a different set of icons for each platform is really stupid. It’s hard enough to get a single icon and now we have to prepare a set of different icons.

    About the changes about de-compressing or keeping the xpi as is, I think that this change should be handled at the AMO server, we just upload the xpi and then the server recompress or changes the format however it thinks it’s better to the users.

    1. Tony Mechelynck wrote on

      About the changes about de-compressing or keeping the xpi as is, I think that this change should be handled at the AMO server, we just upload the xpi and then the server recompress or changes the format however it thinks it’s better to the users.

      Sure: so currently (unlike previously) the xpi is left as-is in your profile because the current opinion is that “it’s better for the users” (in this case: faster, not only to install, but also to run). And then what happens when one part of the xpi tries to read (or execute) another part of the xpi at its old (decompressed) location? Simple: “Error: No such file or directory”.

      The format on the servers has not changed; what has changed is the format after installation.

  17. another_sam wrote on

    please write

    I can’t find how to replace the statusbar by the addonsbar.

  18. Axel grude wrote on

    Extension Release Notes?

    I have just made my extensions compatible with Fx4, but I am still stumped by the “Release Notes: Loading…” part of each item in the Add-Ons Manager. Could not find any documentation on this, so I added a stub here:


    Can anybody who knows, update?

  19. public void wrote on

    As stated for platform-specific binary components platform-specific directories are removed in favour their specification in the manifest file. However these directories were also used to set platform-specific default preferences for addons. What’s the preferred way to handle these? I can’t think of anything other then a first-run block during the addons initialisation, grepping the os and adjusting the default prefs branch. That seems far clumsier to me then the old solution. Did I miss something?

    1. Jorge wrote on

      No, I don’t think anything special was done for other platform-specific files. Are you sure that you can’t place any files in platform directories now? I haven’t confirmed this myself. If you can’t, then your best bet is the solution you propose, and figure out which preference values to use at startup.

  20. David White wrote on

    You can count me out for FF4 as well. Just downloaded the latest beta. This is a step backwards in my opinion. Plus my ThunderbirdBiff addon is rendered virtually useless due to the departure of the status bar. In addition, all the changes required to change an addon which has worked from version 2 and 3 are simply too much of a pain. All the new requirements. Plus all of hoops that require jumping at AMO are just taking the fun out of this. What a shame. Perhaps it is time to check out Chrome?

  21. Kohei Yoshino wrote on

    A Japanese translation of this article is available at

  22. hirva wrote on

    I am on a project for an extension and i have to start its development in next 2 days. Since the development should be in latest version of Firefox, i am a bit confused on which version of Firefox should i start my development as still FF 4 is not released . and if i start with FF 3.6 there are many changes for FF4 so there will be a rework for me.. kindly guide me for the same as soon as possible.


    1. Jorge wrote on

      Firefox 4 will be available in its final version within a month or two. Once it’s out, it will be a matter of also a month or two before the majority of users migrate to the new version.
      If you want to save some time and effort I would recommend targeting Firefox 4 only, and then try to use any spare time to backport it to 3.6 if possible.
      If you want to target as many people as possible as soon as possible, then it is probably best to support both 4.0 and 3.6.

      1. hirva wrote on

        thanks Jorge,

        one more thing , will it be feasible to start the development in beta versions of FF4?

  23. Palash Jawa wrote on

    as a student i like firefox 3.6 more because of its some extensions like screengrab , web2pdf ,text to voice ,save as pdf and more .but the firefox 3.6 takes more time to open than 4 beta . my question is that if the developers could make these extensions compatible with 4 beta then it would be great because not only it would be fast but also i can also use its interface easily and it would help me a lot in my studies

  24. Dan wrote on

    as a addon developer for Firefox, we encountered problem with Xt plugins – bug

    We are i need of put our application to the blacklist, like Adobe or VLC. Can somebody responsible answer me for further information?

    1. Jorge wrote on

      I’d recommend commenting on that bug. While it is generally considered bad form, I think this bug could use a “bump” to see if it can be fixed before Firefox 4 is released. You can also try contacting Benjamin; he might be able to help you with this.

  25. patrickjdempsey wrote on

    Hi Jorge, I just wanted to get a little info out there. I’ve been working on updating my Themes and it seems that some of the changes in 4.0 will cause errors to appear in the 3.6 Error Console. These errors have no impact on Firefox or on the Theme itself, but reviewers testing 4.0 compatible Themes in 3.6 will probably not approve the theme.

    Of course, the *official* Mozilla answer to this is to use the appversion flag in the chrome.manifest. This is great for extensions with only a few lines of CSS or XUL, but for a full Theme with thousands of lines of code and hundreds of images, it’s simply not acceptable to double the size of the Theme just to remove error messages that have no actual impact.

    With that in mind, Pardal wrote a brilliant little tutorial here that shows how you can work around the limitations imposed on the way Themes are allowed to use skins:

    His demonstration if for fixing problems arising in different OS’s but can be used equally for any manifest flag.

    1. Jorge wrote on

      Thanks for the info, Patrick. FWIW, your review shouldn’t have been rejected based on Console warnings alone.

  26. Aniket Damle wrote on

    Hi FF-Dev,

    Will there be Firebug add-on added to Firefox 4 RC? As my main intention of changing the FF3.6 to 4 was to try Firebug and test UI features.

    Please include Firebug soon….

  27. Tunks wrote on


    I just installed F4 and I cannot for the life of me get my no script, quick proxy (all updated) to show on the addon toolbar?

    What needs to be done?

    1. Jorge Villalobos wrote on

      I bet that at least NoScript works correctly with the Add-on Bar. It should be easy to open the Customize Toolbars and move the buttons down there. You also need to enable the toolbar from the View > Toolbars menu.

      If you have more specific problems that this, I recommend you take them up to the developers of the add-ons. You should get a quick response.

  28. Bob wrote on

    In 3.8 Firefox I was able to close Firefox browser and have the option to save window app tabs now I don’t get this choice please return this feather locking the app tabs is not the same

  29. John wrote on

    Which of the two add-ons, if any is compatible with Firefox 4.
    1. No Do Follow
    2.Affiorama SEO Toolbar 0.973

    If none of these two are compatible, Is there a similar add-on that is compatible with Firefox 4 ?

    1. Jorge Villalobos wrote on

      1. I couldn’t find that one, but there are many privacy add-ons if you search for “privacy” on our site.
      2. I found it and it’s incompatible for now. Searching for “SEO” should give you a few useful results as well.