Extension Developers – Breaking News

Some extension developers using nightly versions of Firefox 3 may have noticed (as Doron Rosenberg did) that a recent change caused some extensions to break. Bug 414836 changed the ID of the <toolbox> used in browser.xul, the main Firefox window (“navigator-toolbox” was changed to “browser-toolbox”). Doron filed bug 415099 to try to get the initial problem fixed another way. I don’t think that will happen as the other ways which were tried caused Ts regressions.

Doron also posted a workaround that nicely handles the problem:
(assuming you are overlaying a vbox into the toolbox)

<toolbox id="navigator-toolbox"> 
  <vbox id="your-id"></vbox>
<toolbox id="browser-toolbox">
  <vbox id="your-id"></vbox>

<vbox id="your-id" class="your-class">

You frequently see this approach used in XUL overlays that target Firefox and Thunderbird too.

Ratty (on IRC) also notes that other element IDs have changed too. I am going to get a list of the changes and post them to the MDC article on updating extensions.

Snarky Note: The original bug was a problem in the data persisted in localstore.rdf which would have been much easier to fix if it was localstore.sqlite

Update: Other toolbar related element IDs have been changed as well (in bug 404109) so I thought I’d let you know sooner than later:
“nav-bar” -> “navigation-toolbar”
“PersonalToolbar” -> “personal-toolbar”

7 Replies to “Extension Developers – Breaking News”

  1. We’ve recently been working on getting the id in Songbird’s mainwin.xul to match those in Firefox’s browser.xul. Should we copy these new IDs?

    Snarky Note:
    Off the top of my head:

    // get the rdf service
    var rdfSvc = Cc[“@mozilla.org/rdf/rdf-service;1”].getService(Ci.nsIRDFService);
    // get the localstore datasource
    var localstore = rdfSvc.GetDataSource(‘rdf:local-store’);
    // get an nsIRDFResource for the navigator-toolbox item
    var navigator_toolbox = rdfSvc.GetResource(‘chrome://browser/content/browser.xul#navigator-toolbox’);
    // enumerate its properties
    var properties = localstore.ArLabelsOut(navigator_toolbox);
    while(properties.hasMoreElements()) {
    var property = arc_labels.getNext();
    // enumerate the values for this property
    var targets = localstore.GetTargets(navigator_toolbox, property, true);
    while(targets.hasMoreElements()) {
    // clear the value
    localstore.Unassert(localstore, arc_label, targets.getNext());

    now, that wasn’t too hard was it?

    I’ve had enough of the irrational rdfoibia.

  2. > I don’t think that will happen as the other ways which were tried caused Ts regressions.

    Couldn’t that be done from within the code called on upgrade (whatever triggers the compatibility checking and the display of the whatsnew page)?

  3. “nav-bar” changed into “navigation-toolbar”, not “navigator-toolbar”

    And – it’s a shame that a change like this is introduced after the extension developers have been encouraged to update their extensions. Not to mention that resetting all toolbars to their defaults might put off a few users (and confuse many others who will try to find the extension icons they never had to add manually before).

  4. auto hide bookmark toolbar
    code in userChrome.css

    #personal-toolbar {display: none;}
    #browser-toolbox:hover > #personal-toolbar {display: -moz-box;}

    but why it does not work with livebookmark?
    when i click the title(livebookmark), it does nothing.

    please help, thank you.

  5. I’ve poked through the docs some and applied updates based on this info. Someone should feel free to make sure I’ve not missed anything of value.

Comments are closed.