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
Doron also posted a workaround that nicely handles the problem:
(assuming you are overlaying a vbox into the toolbox)
...
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”
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.
> 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)?
“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).
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.
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.