我们已经移除了扩展程序的工具栏（包括状态栏）。您不应再依赖它的存在。已有一个填隙片会尝试迁移您的图标，但它可能不起作用或只能部分起作用。 最好的解决方案是更改按钮的位置。 这也许是一个很好的时机去考虑您的扩展程序是否真的需要在默认情况下对所有用户可见的工具栏按钮。使用扩展程序SDK开发的扩展程序不需要注意这次改变。
我们已经移除了应用(Firefox)菜单。 取而代之的是一个新的基于面板的菜单，可以用导航栏远端的一个按钮打开它。可以将工具栏项目拖进/拖出这个面板。
一些默认的工具栏按钮ID已更改，我们添加了一些新的ID，并且后退/前进按钮，URL栏，停止/重新加载按钮的顺序将不再可自定义。这也意味着用户不能用常规的自定义流程在这些按钮中添加新的(扩展程序提供的)按钮。
独立的暂停刷新按钮已被移除
我们正在更改工具栏按钮的添加方式。 虽然我们尝试保持某种向后兼容性，但是以下的 the following are deprecated and will be removed in the near future: the toolbar.insertItem 方法， toolbar.currentSet 属性, and the currentset 属性 on toolbars. If possible, please stop relying on them. Instead, you should use the CustomizableUI module.
CustomizableUI introduces a new API to insert, move and remove toolbar buttons and other toolbar items, as well as creating panels that are anchored to these toolbarbuttons. We believe this will be simpler and more powerful than the previous mix of APIs.
Because of the new customization APIs, your toolbar buttons may not be direct children of a XUL <toolbar>; they might still be in a toolbar, or they might be in the "customization target" of a toolbar (a descendant node in a toolbar), or they might be in the new menu panel. The customization target of any toolbar (whether the target is a child node, or the toolbar itself) via toolbar.customizationTarget.
Icon sizes in toolbars have changed, and you should ideally provide a larger icon for your add-on's buttons, should they exist, for use in the menu panel and customization area (palette). The new icon sizes are the same on all platforms and are:
When in the customization area (palette), the button will be wrapped in a toolbarpaletteitem with a place attribute set to palette. Putting it all together, your updated CSS might look like this:
#my-addon-button {
list-style-image: url(icon16.png);
}
#my-addon-button[cui-areatype="menu-panel"],
toolbarpaletteitem[place="palette"] > #my-addon-button {
list-style-image: url(icon32.png);
}
/* High-resolution displays */
@media (min-resolution: 2dppx) {
#my-addon-button {
list-style-image: url(icon32.png);
}
#my-addon-button[cui-areatype="menu-panel"],
toolbarpaletteitem[place="palette"] > #my-addon-button {
list-style-image: url(icon64.png);
}
}
Tab markup and styling have changed. If your add-on affects the tabstrip or provides alternative visualizations of the tabstrip, changes tab colors, or anything else related to the tabstrip, you may want to verify that it still works.
The navigation toolbar is always visible (except in popup windows where a reduced navigation toolbar with the urlbar is visible) and can no longer be hidden e.g. for update pages or in-content UI. The related Add-on SDK module addon-page has been removed as it no longer has any effect.
Items in the navigation toolbar can be overflowed if the browser window is made too small. Items in the toolbar will be moved into the new "overflow panel" when this occurs. The overflow panel is anchored to a button that appears in the navigation toolbar when one or more items are overflowed. If your item should never be overflowed, set an overflows attribute to false on the item. The urlbar-container is not overflowable by default, for example. Items that are overflowed have the overflowedItem attribute set to true.
The menu panel uses a 3-column grid layout. Items should either fit in a single grid column (toolbarbuttons will be styled to do so automatically) or span the entire width of the panel if they wouldn't fit in a single grid column, e.g. for wide toolbaritems. In order to have the latter work correctly, you should use the panel-wide-item class on your toolbaritem.
If your add-on provides a <toolbarbutton type="menu"/> or <toolbarbutton type="menu-button"/>, consider moving to a subview-based design, which will work much better in the menu panel. There's some documentation you can look at, as well as the implementation of the history widget.
If your add-on provides a simple toolbarbutton then it should automatically be styled correctly in the menu panel, overflow panel and palette. If it provides a toolbaritem it is likely you will need to do additional work to make it look nice in places other than a toolbar.
All items will have context menus allowing users to move the items between the palette, panel and the navigation toolbar. If your add-on uses the contextmenu itself, we will not override or change it (see this bug for a lengthy discussion as to why). You are requested, however, to update your menus yourself so that users do have the possibility of using these options even for your add-on's button.
The class attribute on tab close buttons has been changed. Extensions shouldn't be relying on the class attribute value since it is a list of tokens and should instead look for the anonid attribute with value "close-button".
The close-icon class now works cross-platform to provide a close icon with a default, hover, and active state. Previously, this wasn't available on Linux and the GTK close icon (gtk-close) was used instead.
The BrowserToolboxCustomizeDone, BrowserToolboxCustomizeChange, and BrowserCustomizeToolbar global window functions have been removed. The customize events fired from the toolbox are now the preferred mechanism for hooking new logic into the customization feature.
If you're using the Add-on SDK, there are several new APIs for building your add-on's user interface in Australis. See the reference documentation. Also note that the widget module has been deprecated in favor of the new APIs.
We've changed the tab markup. If you style these differently, you'll need to check whether it still works.
We'll be drawing tabs in the titlebar and on top, on all platforms (currently implemented on Windows and OS X), except when not showing tabs at all (in popup windows).
Support for small icons mode as well as text and icons mode have been removed.
We've changed the default iconsets, and there are new icon sizes for the menupanel. If you're building on the default theme with new icons, you'll need to rearrange your icons in your Toolbar icon files. In both this case and if you supply a complete theme, you will also need to provide icons for the menu panel. The new icon sizes are the same on all platforms and are:
We've removed the add-on bar, but have a shim in place to migrate icons to other places. Any styles pertaining to should be removed so as not to disturb the migration work.
We've changed a few toolbarbutton IDs, such as those for the bookmark and history buttons. We also added new ones.
The application (Firefox) menu has been removed.
The back, forward, stop and refresh buttons will no longer be movable. They will always remain in their current position next to the urlbar. Your CSS rules can probably be simplified now that this is the case.
The navigation toolbar can no longer be hidden e.g. for update pages or in-content UI.
document.getElementById(). This is no longer enough. If your button is in the menu panel, it will not be moved there until the menu panel is first shown. Instead, use: CustomizableUI.getPlacementOfWidget("mytoolbarbuttonId"). This will return null if and only if the widget is in the palette.<menulist> element is wrapped inside a toolbaritem, popping up the <menulist> closes the new menu panel. This issue is being tracked here.menu with a orient="horizontal" attribute will not display properly in the menu panel. This attribute should probably be avoided altogether.