Mozilla Add-ons Community Blog
Categories: compatibility developers documentation

Australis for Add-on Developers – Part 1: Toolbars

52 responses

Australis, the new Firefox theme, landed in Nightly 6 weeks ago. Because of the ongoing work being done to it, it won’t be uplifted to Aurora just yet, so it will continue to be available exclusively in the Nightly channel for at least one more cycle. That means that Australis won’t be in Firefox before version 29, which is currently scheduled to make its final release in late April 2014.

We encourage you to download the latest Nightly and test your add-ons in it. If you’re an add-on developer and run into problems, please let us know, or file a bug and add it as a dependency to this tracking bug for add-on issues on Australis. Make sure to give the other dependent bugs a look first to prevent duplicates. If you’re not a developer and want to report a problem in one of the add-ons you have installed, you can install the Add-on Compatibility Reporter extension and use it to let us know.

Now let’s start looking into what has changed in Australis that you should know about. If you haven’t installed Nightly yet, you can use the information in this blog post as reference.

Toolbars

The toolbars have changed significantly. The objective is to maximize the content area available to users by cutting down chrome areas that were generally empty. There were also deeper changes that enable more complex widgets to be added to the toolbar and other areas without compromising on space.

The Add-on Bar at the bottom has been removed. Instead, there’s a new menu panel that extends the toolbar with buttons and widgets. It is activated by clicking on the button at the right end of the main toolbar. All the items in this new menu are customizable and it’s possible to add add-on buttons and widgets to it as well.

The customization UI got a much-needed refresh and now it’s much easier to use and find. The full window view allows users to better understand what they’re doing and have better control over toolbar customization. The possible targets for toolbar buttons are the main toolbar, custom toolbars, the tab bar and the new menu panel. Make sure that your add-on buttons / widgets work well for all cases. There’s currently no way to create new blank toolbars, but the Bookmarks Toolbar can be used by users to add buttons. There is no more big icon / small icon option.

The DOM in the main toolbar is also different. Now there’s a intermediate container between the toolbar element and its children. It’s an hbox with id nav-bar-customization-target.

Toolbar Buttons

The icons in the main toolbar are 18×18 pixels. However, a 1px padding is expected, so the 16×16 pixel icons you should be using for the main toolbar in modern versions of Firefox will work without any changes.

Buttons can be also moved by users or added by default to the new menu panel, so you need to consider this case as well. Icons are 32×32 pixels in the menu panel and also during customization, if they are removed from the toolbar. Smaller icons will be upscaled, so they won’t look very good if you use the 16×16 pixel icons.

So, if you have an add-on that adds a toolbar button to the main toolbar using the usual guidelines of overlaying the button to the palette and then adding it to the toolbar using JS on first run, everything should work the same and you should only change your CSS to something like this:

/* Original CSS */
#my-button {
  list-style-image: url("chrome://my-extension/skin/icon16.png");
}
/* Added for Australis support */
#my-button[cui-areatype="menu-panel"],
toolbarpaletteitem[place="palette"] > #my-button {
  list-style-image: url("chrome://my-extension/skin/icon32.png");
}

Note that buttons in the Australis theme have the cui-areatype attribute set when placed in in the UI. The possible values are menu-panel and toolbar. You can use the toolbar value to have different style for the button in Australis and non-Australis themes.

Buttons with type="menu" or type="menu-button" show inconsistent appearance and behavior. There are a couple of add-on bugs filed for them, but it’s unclear if they will be fixed, since the subview pattern will be favored for Australis. See how the History button works on the toolbar and the panel for an example of this. The process of implementing this isn’t documented yet, but you can look at the source code to get an idea.

Add-on Bar Buttons

As mentioned before, the Add-on Bar was retired to maximize the available content area. However, a shim is in place in the main toolbar to facilitate migration (it even contains the old statusbar shim). However, it doesn’t seem to work at present. I filed this bug to keep track of the problem.  While this does appear to be a bug, we encourage you to insert your button in the main toolbar instead.

By the way, an easy way to detect if your add-on is installed on a Firefox version with Australis is to check for the existence of this node ID: PanelUI-menu-button.

SDK Add-ons

As you may know already, the SDK was integrated into Firefox, so SDK add-ons no longer need to bundle the entire set of libraries, making them more or less independent from the SDK version being used. Version 1.15 of the SDK was just released, which generates library-less XPIs by default.

Since the SDK will be built into Firefox, you can expect your add-ons and widgets to work with Australis. You should keep in mind that it’s possible that widgets will be deprecated in the future for something that works better with Australis, but that’s still being talked about, so keep an eye on this blog for updates.

More Documentation

  • CustomizableUI.jsm. This module is the tool that add-ons can use to manipulate the toolbar and its widgets directly. The document is still taking shape, so you might need to look at the source code directly for up-to-date information. Bonus points if you contribute to the doc :).
  • Australis and Add-on Compatibility (draft). At the moment it’s just a collection of compatibility notes. It’s also being worked on, so it will change in time. And, again, bonus points ;).

As the title says, this is only part 1. As we learn more about the compatibility issues add-on developers run into, we will release new installments. Part 2 covers the CustomizableUI object. Let us know what you have discovered about Australis compatibility in the comments.

52 comments on “Australis for Add-on Developers – Part 1: Toolbars”

  1. Alfred wrote on

    Some justifications make for me little sense being for a desktop environment, but, anyway… I have a question: why not XUL for the new widgets? If I need to keep compatible a menu button it seems that I will need to have some (not much) duplicated logic for the button (xul & customUI.jsm). Is it?

    Sorry by my English, btw.

    1. Jorge Villalobos wrote on

      The trend is to avoid XUL as much as possible, since it is a custom technology used only by Mozilla and a few other parties. Using HTML makes it easier for the SDK, which already hides most XUL, Android add-ons which use no XUL at all, and would in theory make it easier to create cross-browser add-on widgets. You’re right that it requires some code duplication to maintain old and new versions of Firefox during the transition period to Australis.

  2. Peter J. Sloetjes wrote on

    Could Australis simply be made to load an ‘icon.*’ or ‘icon32.*’ from the extension root if it exists? Since ‘icon.*’ is recommended to be 64px64, this avoids the risk of up-scaling in most cases. Also, given that quite a few add-ons (including themes and plugins) are lacking icons, I think that adding them should be made as simple as possible.

  3. Ken Saunders wrote on

    First of all, thanks for starting this.

    Currently toolbar buttons with type=”menu” and/or or type=”menu-button” aren’t keyboard accessible (a bug or two has existed for a while).
    Will this change for buttons items in the menu-panel? Will we be able to provide an accesskey?
    —

    User point of view.
    “We’ve removed the application (Firefox) menu. Instead, there is a new panel-based menu”
    But the items that were under the application menu aren’t there or are they and I’m just missing something.
    So how does one access the items that were there? Is F10 (toggle menubar) the only way?
    —

    “The trend is to avoid XUL as much as possible, since it is a custom technology used only by Mozilla and a few other parties.”
    But it’s Firefox add-ons for Firefox desktop so what does it matter. A good amount of the most used and better add-ons use XUL.

    “in theory make it easier to create cross-browser add-on widgets”
    Why would Mozilla want this when it is still the add-ons made specifically for Firefox that retains a large amount of users and sets it apart in many ways from other browsers.

    Granted, some Firefox add-ons are available for Chrome and other WebKit browsers, but they’re written for WebKit browsers aren’t they and they have limitations.
    What other ways can Firefox have a competitive edge if the add-ons can be used in any browser?
    I read a huge amount of user and ex-user comments around the Web and Mozilla’s values and missions aren’t the deciding factor for using or not using Firefox (is for me in many ways). In fact, especially with Australis, on the surface, and as absurd as it is, the average user doesn’t see the differences between browsers.

    I see some of the numbers for active users of add-ons and understand that compared to 450 million or so, the total number of add-on users isn’t massive, but those users are also advocates and free advertisers for Firefox and Mozilla.

    I’m not trying to give you a hard time in particular because I know that you’re not the master helmsman of the ship, and I like you personally and professionally, but when jetpacks started, you said the plan wasn’t to phase out XUL. Have you changed on this?
    If you were talking about writing add-ons that would be compatible across just Firefox desktop, OS, etc and not other browsers, that would be one thing and totally understandable because there would be a competitive edge left in place, but that doesn’t appear to be the case.

    Sorry if I’ve misunderstood something.

    1. Jorge Villalobos wrote on

      …keyboard accessible (a bug or two has existed for a while). Will this change for buttons items in the menu-panel? Will we be able to provide an accesskey?

      I don’t know about accessibility, sorry. If there are bugs filed for these issues, that’s the place where the followups should happen.

      So how does one access the items that were there? Is F10 (toggle menubar) the only way?

      I think so, yes. If there are other ways, I don’t know about them.

      But it’s Firefox add-ons for Firefox desktop so what does it matter. A good amount of the most used and better add-ons use XUL.

      It matters because using open and standarized technologies is very important for us. It’s also important for developers because it makes it easier for them to get started with technologies they already know about, and they can create add-ons that are portable.

      Why would Mozilla want this when it is still the add-ons made specifically for Firefox that retains a large amount of users and sets it apart in many ways from other browsers.

      Are you suggesting we should be intentionally anti-competitive?

      you said the plan wasn’t to phase out XUL. Have you changed on this?

      XUL will not stop being a part of Firefox or add-ons in the forseeable future. It’s integrated too deep into the platform for this to even be possible. We want add-ons to use open technologies and be portable, and that means discouraging XUL. However, developers are still free to use XUL if they want.

      Sorry if I’ve misunderstood something.

      No, I think we just disagree on whether it’s good or bad for add-ons to be portable.

      1. Luke wrote on

        “Are you suggesting we should be intentionally anti-competitive?”

        I think he’s not saying you shouldn’t be “intentionally anti-competitive”, but that you should use the best technology for the job. That Chrome and other browsers don’t use the more clear and easy-to-use XUL technology, that is also well documented (https://developer.mozilla.org/en-US/docs/XUL) and open source, is their mistake and should (hopefully) be corrected in the future.

        Is there anything really equivalent to how XUL overlays can modify others, in HTML?

        1. Jorge Villalobos wrote on

          I think it’s fine to use XUL when it does the job best. Generally it would be better to use HTML since it is a more widely-used and open technology, which is why we encourage it for new things. If that doesn’t work, XUL is always there.

          And no, there isn’t an equivalent for XUL overlays in HTML, that I know of.

  4. Kohei Yoshino wrote on

    The Japanese translation is here: https://dev.mozilla.jp/2013/12/australis-for-add-on-developers-1/

    1. Jorge Villalobos wrote on

      Thank you!

  5. Gomita wrote on

    Another way to detect Australis: “CustomizableUI” in window

  6. Jos Tor wrote on

    This is waaaaay off-topic, but I think you might be able to make more of this than I can.
    One of the recent updates that included the new toolbar and customization interface has broken the add-on ‘AnonymoX’s interface, and subsequently, all of firefox now starts with no web pages visible UNTIL I open the customization window, and then close it, regardless of the new tabs I open. This is getting really aggravating, as any new window opens this way (some are mini player windows that are supposed to be plug-in containers, a la espn live streams that do not have the customization button, and are subsequently rendered unable to be viewable). Moreover, I can’t even access the add-on interface to turn it on or off. If I try to open it through Tools, it gives me ui error, and asks me to report it. I have reported it for the last 2 weeks to the add-on developers, and I’m sure they’re working on a release, but I’m seeing the same thing about other add-on interfaces on simple google searches. Why on earth would Mozilla release a version of firefox that denies ui access to add-on interfaces????

    1. Jorge Villalobos wrote on

      Try starting Firefox in Safe Mode and disabling the add-on that is causing this problem.

  7. Peter J. Sloetjes wrote on

    I like the Australis design style-wise. However, a layout that favors touch devices should have more (not less) directly-accessible toolbar space in order to retain accessibility (~ click depth!). In my opinion, a back-translation to large-screen (desktop) devices is needed, involving the following:

    1) an option to make widgets overflow into a second (or third) line in the same toolbar (instead of in an additional panel),
    2) an option to toggle the menu panel into a full-height, variable width, semi-permanent sidebar, and
    3) recursive panels within the menu-panel that are meant to replace recursive menu’s in XUL.

    Implementing these features is trivial, so add-on developers will probably provide them anyway, but I would love to see them provided to all of us (desktop users).

  8. patrickjdempsey wrote on

    Reading the comments about XUL makes me glad I decided a few months ago to switch over to SeaMonkey. XUL is so vastly superior to HTML for layout and extensions that I cannot even fathom how ridiculously limited and lame an HTML-based extensions system would be. I guess all this mucking about in Android-land has caused Mozilla to loose faith in THE thing that made Netscape and Firefox great. That’s even more deeply disturbing and sad to me than the gutting of Customization. 🙁

    1. Jorge Villalobos wrote on

      XUL isn’t going away any time soon since it is an integral part of the Mozilla platform. HTML is being favored when possible, though, and it’s not that difficult to create complex layouts using CSS flexible boxes. I don’t know what the plans are for SeaMonkey, but it might be more difficult for them to branch out the old UI than just adapt the new one.

  9. SaphirJD wrote on

    You know, removing stuff which seperates you from the competition (Chrome) makes you not look better, no it makes you worse.

    Why should people use Firefox when it looks like Chrome, works like Chrome and becomes limited addons like Chrome, when you really thinking about pushing xul more and more to the background..

    Same goes for your Australis survey – It is not enough for you anymore to restrict customization, you SERIOUSLY start thinking about getting rid also of Full Themes or the UserChrome.css?

    Again, if you keep not features which puts you above the competition, why should anyone use Firefox?

    “Are you suggesting we should be intentionally anti-competitive?” – Yes, you should be, if it brings you more market share as compared with other Browsers! Or are you so desperate to go out of business and push all users to Chrome?

    Anyway, i am still using Firefox 22 until i see what happens with Palemoon or Cyberfox – and after that i will change Browsers. I will not support a Mozilla which dream is to be like Chrome or to be like the rest of the competition in general

    Please, stay “anti-competitive” – keep Full Themes, customization and all the stuff which pushes Firefox above the Competition. This is how success is reached, not by removing features and wishing to be like the boring rest!

    Be unique, stay Firefox!

    1. Passerby wrote on

      I disagree with one of your point. Moving to other browser is not an good option, should decide to then you will have to rely on these 3rd party “compiler” which will either choose to support Australis and deny it.

      Assuming they deny any changes that is related to Australis, how long can they keep up? From what have been posted in the past about the Holly builds (Nightly but Australis free), it was said that maintaining this fork(?)/build is difficult and will be stop once Australis go stable. Consider Mozilla should have the most knowledge and internal resource/information available and yet can not maintain a Australis-free version, people that fork Firefox (Icewesal, Palemoon and Cyberbox to name a few) would have trouble sooner or later creating this Australis-free version of theirs.

      So that left you with other option such as Opera, Chrome, Safari or any other fork of Chrome such as Comodo Dragon. Opera is already becoming Web-kit Chrome like (see version later than 12.16), and Chrome is Chrome. Safari, I have little knowledge about aside from it being Webkit also. Moving to these browser does not seem to suit you either, due to your “I want my browser to be ‘my’ browser, customized it the way I want”.

      So what option do you truly have left? None really. You have to “deal with it”, “suck it up” and just keeping using Firefox. Although Mozilla is taking away many of it features that it boast from the past it still is (currently as of v29) the most customizable. You can not move, move to what. You have to use Firefox, watch it live or burn, keep using it, you do not have any choice.

      With that said, what can you do? Nothing much consider how things is, have ‘hope’ is one option. But there is one thing (or two) you can/could do, the first is obvious (1) Use Firefox no matter what, you probably grown up with it hope Mozilla can be enlighten and (2) Tell anyone who ask you for advice along the lines of the following;

      “Just use Chrome or the like such as that of Opera. Why not Firefox like I am? Because it does not offer anything else unless you spend hours on it (Add-on, Userstyle, Tweak that will probably be remove by the time you them these thing). I only use it because it is too late for me, it is like my child sentimental speaking. You(s) however can use Chrome, given years later perhaps Firefox can be similar (if not already) to Chrome too, then any of the three (or four) major internet browser will be the same and picking any will guarantee the you’re using the result of the ‘peak of internet browser’.”

      See you in 2014 or 2015 when Firefox is once again revolutionize the way it should be.

      1. SaphirJD wrote on

        Well, i still would go with that third Party builds like Palemoon or Cyberfox.

        In case that they also adopt Australis there is still Seamonkey which is 100% Australis free in the Future. More then enough Options.

        And in the truly worst case, why should i stay with Firefox when there is also the original Chromium available.

        So Palemoon, Cyberfox, Seamonkey or Chromium it will be. But i will in no case Keep on using Mozilla’s Firefox which Goal is to become like Chrome. If that’s the case and it can not be avoided with any other Gecko related Browser, why staying on Firefox then.

        It’s that simple!

        1. SaphirJD wrote on

          Still using Firefox with Australis is truly giving up. In that case you are saying nothing less as “Good work Mozilla, your own Chrome similiar Browser rocks hard!”

          And this Option is not my Option. If you would do that, fine. But there are People around for which “Mozilla Chrome” is 1000% no Option at all worth considering 😉

    2. Daniel wrote on

      + 1

      Hear ye!

    3. clas wrote on

      good comment….”Please, stay “anti-competitive” – keep Full Themes, customization and all the stuff which pushes Firefox above the Competition. This is how success is reached, not by removing features and wishing to be like the boring rest!”

      and i am even slower to adapt new changes. still on ff16-18 and all works great. why would i change?

  10. Peter J. Sloetjes wrote on

    Like many add-on developers, I have chosen menu-buttons as user interface elements for all of my add-ons, because these provide the best trade-off between size, accessibility, and ease of customization. Now Australis strongly reduces the available toolbar space and drops support for menu-buttons, thus increasing the amount of clicks for accessing the primary state or action of many add-ons from one to three (open menu panel -> open add-on panel -> click button). The only alternative, providing multiple customizable toolbar buttons, is, although feasible, less convenient and more confusing for users.

    Besides the trick I proposed in my previous comment for increasing the available toolbar space, I recommend prolonging the support for menu-buttons by: 1) preventing their malfunctioning (sic), 2) setting their width in a toolbar to twice that of a normal toolbar button and 3) splitting their area in the menu-panel horizontally in two parts, one with a 32×32 icon and one with a large menu drop-down icon (which should still allow for touch access).

    Also, items in the overflow panel need to be customizable as well …

    1. Jorge Villalobos wrote on

      Well, menu buttons still work, but they might need some additional code to work like they did before. You can still add buttons to the main toolbar, so it’s still possible to have a one-click experience. The only limitation there is that there’s less toolbar space for buttons because of the lack of an Add-on Bar.

      What do you mean when you say that the items in the overflow panel need to be customizable? You can add or remove any items you want from that panel (unless I’m misunderstanding what you mean).

      1. Peter J. Sloetjes wrote on

        Well, given bug 940307 and other bugs, I do not expect menu buttons with recursive menu’s/panels to work well in Australis any time soon.

        As to the overflow panel, for a previous version, this panel was visible in customization mode, but could not be customized. The current version hides the overflow panel in customization mode, which leads to invisible toolbar items (if the window is narrow). I do not understand why not the simple solution was chosen to let toolbar items overflow to as many toolbar lines as necessary.

  11. tux. wrote on

    I love how intentionally force-removing the add-on bar increases screen space even for those who like to keep their add-on functions visually separated from the main toolbar…

    Make it optional – fixed for everyone!

  12. Vengeance wrote on

    Agree with the above comment.
    Keep the add-on bar and just default visibility to off. You save display area for the users who have no extensions using the add-on bar and the users who do use it, know where to enable it.

    However Mozilla have to treat everyone like morons and ruin the browser.

    If this is not rectified by the time it hits full release I suspect a lot of users, myself included, will move to a fork of Firefox.

  13. Axel Grude wrote on

    Why I think complete removal of the Addons bar is a bad idea: I use the addons bar to persistently display important information and also to toggle certain page specific commands, here is a screenshots that shows my typical usage:

    http://imageshack.com/a/img713/2605/ezk0.png

    while I would concede that I could probably remove 2 or 3 of these buttons, I would have to keep the rest of them as they are used almost daily. I can toggle the Addons bar with CTRL+/ to maximize screen space. The problem presented is that if you remove the Addon bar at the bottom, these persistent buttons (which convey some context specific information at a glance) would have to be moved to the toolbar (which also has some important commands in it). At least for me as a power user and developer it would come to a point where to many things are displayed and the screen space gets crammed up.

    So while this probably doesn’t make a difference for the average “lite” user, you are creating a serious usability problem for people who use more Addons, which in fact seems to encourage people not to use Addons (or use less). Could you commission somebody to write an Addon to get the Addon Bar back? even better, give a choice to install it when downloading / installing Firefox, similar has been done with some addons (such as compact header, lightning) on Thunderbird.

    As a personal observation I do not really see much value in removing a feature to “force users to maximize their screen space” unless you want to get rid of Addons doing UI modifications altogether. Also as User Interface designer with 25 years experience in the business I know that dialogs are best for structured configuration so I cannot see the push to move everything into a HTML web page (and confusing chrome level configuration with content) as an evolutionary step forward.

    1. greg wrote on

      Agree. Don’t know how this present trend of less choice is better got started but it has become a bit of a pita, so much so that IE is starting to look like a reasonable choice again.

  14. Mingyi Liu wrote on

    I like the new UI – a bit copycat on surface but much more customizable and functionally accessible than Chrome’s.

    That said, it does cause my Fastest Search (Jetpack) addon to stop working (the other 4 of my 5 public addons all worked fine, 2 XUL ones and 2 Jetpack ones). The only error message is “Could not read chrome manifest ‘file:///C:/Program%20Files%20(x86)/FirefoxNightly/chrome.manifest’.” But the same message comes up in some other Jetpack addons (including mine) that do work in the Nightly.

    Nightly does report that the installation of Fastest Search 3.29 “finished successfully”, yet I don’t see its icon and none of the functionality works. There’s no info in this post that’d explain why my addon failed to work. Can anyone either look into this or provide a detailed changes post? There must be some XPCOM changes that affected my addon that caused it to fail, as FS uses XPCOM quite a bit. Thanks much!

    1. Mingyi Liu wrote on

      BTW, I’ve tested FS3.29 in 28Aurora earlier and it worked fine. So the issue is only with 29Nightly.

    2. Mingyi Liu wrote on

      BTW, when I showed 8 yo the new Chrome-like UI, he’s like “Noooooo … that (UI) is what I don’t like about Chrome!”. But then I showed the better features to him and he’s like “That’s nice”. So the naysayers might just need a bit time or a more detailed video …

      1. Axel Grude wrote on

        “So the naysayers might just need a bit time…”
        …and the inconvenience of using the mouse to look up a lot of status icons (tiome, adblock, noscript, lazarus, colorzilla, extension test etc.) or overloading the toolbar with way too many buttons.

        anyway there is already an Addon “The Addon Bar” putting back this vital functionality for those of the users who didn’t run off to Chrome.

    3. Jorge Villalobos wrote on

      My guess is that the way you’re adding your button to the Add-on Bar is what causes it to fail in Australis. I don’t see the button at all, not even in the customization panel, so I suspect that’s where the problem lies.

      As recommended in the article, you should try injecting the button in the main toolbar directly instead of in the add-on bar. Otherwise, I think the best approach would be to file a bug explaining how you’re adding your button. Perhaps it’s something that can be fixed in the Add-on Bar migration code.

      1. Mingyi Liu wrote on

        I just had some time to check more. Turns out it’s actually the deprecated tab-browser causing trouble. I used to use require(‘tab-browser’) but a few versions ago I had to use require(‘sdk/deprecated/tab-browser’), and apparently in FF29 the deprecated modules are finally gone, causing my addon to fail.

        That in itself is not a problem (although shouldn’t FF have warned about the missing module instead of silently failing, yet reporting installation “finished successfully”?), but when I tried to find a replacement for the original tabBrowser.activeTab (the active XUL tab), I found two issues:
        1. It’d be nice if DMO hosts older SDK version’s doc too – I had to use Google cache to find out about the old tab-browser doc.
        2. More importantly, the supposed replacement:
        var { getActiveTab } = require(‘sdk/tabs/utils’);
        didn’t work in the nightly. It fails silently too.
        Do you know why?
        Thanks.

        1. Mingyi Liu wrote on

          Update:
          1. I filed a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=963972) on the point #2 above.
          2. I confirmed that this is the only incompatibility in my addon, as I used a XPCOM replacement to get the XUL tab and everything in my addon worked fine so far. Not sure if it’s an exact replacement in all situations, more test will determine that.

          Suggestions:
          1. I think it’d be good to note in future blog that some or all previously-marked “deprecated” modules are gone in FF29. It would’ve helped me find out the issue faster, I’m sure it’d help others as at least some others temporarily use deprecated modules too.
          2. Please have FF warn about missing modules, or anything due to API change, instead of reporting success. It’d help the addon authors save quite some time, particularly when you have to change the API the authors rely on for a while.

          Thanks.

          1. Jorge Villalobos wrote on

            I recommend that you look at the SDK posts that have been published in this blog. If they don’t mention the change that affected you, you should comment there with these suggestions, since they are the ones that should be announcing this sort of thing. I’m not very involved with the SDK, so I can’t help you there.

    4. SaphirJD wrote on

      False, the new UI is not at all a good idea. Many things are not possible anymore without addons. You can not clone the Nav Bar elements in the Tab bar, you can not clone the Nav Bar elements in the addon Bar because it is gone.

      Tabs at Bottom are missing and much more. Australis is just crippling a once wonderful Browser and replaces customizability with Chrome’s Design ideas and minimalistic behavior.

  15. Carpatula wrote on

    Mozilla switched from Opera fanboy’ism over to Chrome fanboy’ism – Once you took your ideas from Opera regarding customizations – but now since Google entered the big picture with their Chrome browser, you just abandoned the concept of customizability and switched over to the design above everything else trend!

    Too bad that i needed that long to realize that you Mozilla guys are only trend followers instead of trend developers. But i have learned now and i am going over to the promising Otter-Browser project, where the dev knows that design is not everything and instead functions should be the thing which should be favored in developement!

    You Mozilla guys have forgotten that point, it is so depressing to see how much you ruin your once great browser!

  16. Quicksaver wrote on

    I realize this blog is more directed to “the add-on developer”, but I think it should still be worth mentioning a couple of things:

    1) There’s a very comprehensive and excellent add-on called “Classic Theme Restorer (Customize Australis)” that turns Australis into something very close to the current theme. It’s definitely worth checking out if you have issues with any aspect of the new design.

    2) For a simpler and more directed approach to the add-on bar (which seems to be the main issue in discussion here), CTR restores it as well. And also, I have written my own add-on called “The Puzzle Piece” (which can be used together with CTR as well) that not only restores the add-on bar, but should help with the migration when updating your firefox, at least for the most part. + it also restores the status bar. + it’s restartless, so it’s easy and fast to see if it’s what you want.

    And as it has been mentioned already, these aren’t the only add-ons already available that specifically customize Australis. For the power user who wants a lot of buttons spread out everywhere they want, they will surely find these options. So it shouldn’t affect any kind of design decisions by add-on developers.

    In my view, as a developer myself, I would initially construct my add-on as if it was the only add-on enabled in the browser, and place my button(s) in the nav-bar with complete peace of mind (a couple of buttons hardly change anything, in terms of clutter). The user who has 50+ add-ons is the one responsible to finding a solution to organize them; these solutions already exist and I’m sure they will only improve from now on until Australis hits release. The new customize system is incredibly intuitive in this regard, which by itself is already an immense help to both the power user and the basic user alike, much more so than the previous (current) customize system ever was. And as long as it doesn’t impede an add-on from making its own modifications, like adding a new toolbar, I say kudos to Australis.

    “Use add-ons to make your firefox unique!” If Australis isn’t following this motto to the letter, then I don’t know what would.

    Just my two cents. 🙂

  17. ThumperZ1 wrote on

    So you are going ahead and not add the add-on bar? Do I hear Win8 debacle only with Firefox??? At least leave it as an option! It can’t be that damned hard since it was there in the first place!!

  18. Minh Nguyễn wrote on

    I wrote up some tips for implementing an Australis toolbar menu icon in SVG: http://forums.mozillazine.org/viewtopic.php?t=2807273

    1. Jorge Villalobos wrote on

      Thanks!

  19. Axel Grude wrote on

    I am trying to get the search bar out of the address bar area (I used to have it in the menu bar) by dragging it to the right of the browser tabs – unfortunately the flex attribute makes the search box waaaay to big (and shrinks the important browser tabs)’; also adding a flexible space between tabs and search box doesn’t help much:

    http://imageshack.com/a/img46/2728/xe9b.png

    I would advocate for more sensible flex attributes should users choose to move the search box up to maximize the space in the addons bar.
    I suggest to set

    toolbar-item#search-container { max-width: calc(54px + 35ch); }

    [min-width is currently calc(54px + 11ch)]

    this will make for some comfortable space for 6 to 8 tabs on my 1680px wide screen:
    http://imageshack.com/a/img841/5379/xuph.png

    1. Jorge Villalobos wrote on

      I recommend you file a bug and ping Gijs about it.

  20. Boris wrote on

    Hi,

    the additional hbox wrapper “nav-bar-customization-target” causes me headaches:

    For Firefox 29 nesting my toolbaritem in the new wrapper in the XUL overlay works fine. However, for the current release and older versions of Firefox the extra wrapper breaks the rearrangement function when customizing the toolbar.
    When dynamically removing the hbox for Firefox < 29 after startup the position of the item is already lost. Conditional blocks in XUL do not exist as far as I know.

    Any suggestions how to introduce the wrapper without breaking backwards compatibility?

    Thanks,
    Boris

    1. Jorge Villalobos wrote on

      Why are you overlaying the toolbar directly instead of using the toolbar palette? Overlaying the toolbar that way has never been accepted.

      1. Boris wrote on

        Thanks, this fixed it. I had misread your update notes …

  21. Boris wrote on

    Hi,

    I have another issue: my addon inserts a toolbaritem into the BrowserToolbarPalette. Enhacing the CSS as suggested in your article has no effect on the appearance in the PanelUI – instead of the icon the full toolbaritem is displayed and the title is missing.

    What’s possibly wrong?

    Thanks,
    Boris

    1. Jorge Villalobos wrote on

      I recommend that you post about this in the Add-ons Forum, where it’s easier to see code and try to figure out what’s wrong. I would also recommend looking at the samples in part 2, both of which have working code and CSS.

  22. Barry wrote on

    Firefox has become unusable by my old people students. Icons are way too small for people that have not too steady hands. They are all complaining. I can’t fathom how you have ignored the ergonomics on 35% of the population. P.S. The flat icons are so ugly and yes the students know that they load much faster but none like them. Please give us some options.

    1. Jorge Villalobos wrote on

      You may be able to find a Firefox theme that has larger icons. The Classic Theme Restorer extension might also be helpful for you.

  23. d.s.e wrote on

    Please enable the Add-on Bar again! It’s ok, to have it not visible in the default configuration for standard users, but as a web developer I have a lot of addons, which really give me important information, so the space IS used.