Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre. STR: 1. Customize toolbar. Observe the Bookmarks icon is missing text when it in the customize toolbar pane. When you drag it to the toolbar and switch to icons and text, then it is properly labeled. Screenshot attached. Seen on Tiger as well as Leopard.

I also see this on XP, same build.

Forgot to say on windows the text disappears after closing the customize dialog. First image, open customize dialog...no text Seconds image, dropped bookmark icon to navigation toolbar...text Third image, text until close of customize dialog

the home button is also missing completely on the latest nightly.

i believe that may be by design. (In reply to comment #3) > the home button is also missing completely on the latest nightly. >

if thats the case, the design is stupid imho.

fine: 20080129_0533_firefox-3.0b3pre.en-US.win32.zip false: 20080129_0733_firefox-3.0b3pre.en-US.win32.zip range : http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1201613580&maxdate=1201620779

> the home button is also missing completely on the latest nightly. You probably have the Bookmarks toolbar hidden, just like I have and I also had a problem to find the Home button. You can find the Home button on the Bookmarks toolbar.

the Home button does not belong on the bookmarks toolbar though, does it.

(In reply to comment #9) > the Home button does not belong on the bookmarks toolbar though, does it. It's now on the bookmarks toolbar by default, per bug 404109. That bug's patch should have reset your toolbars.

Hi, bookmarks icon problem was caused by bug 391002: As #bookmarks-button <toolbarbutton/> is inside a toolbarpalette, it will be removed from document http://mxr.mozilla.org/seamonkey/source/toolkit/content/widgets/toolbar.xml#111 therefore, it's arguments set by broadcasters or command will be removed, and it's label will disappear.

Here, label attribute is not removed because CheckBroadcasterHookup is called again after removeChild. It does not happen in the previous case because xbl constructor seems to be called before initial layout is complete; in such a case, we don't notify document.

that patch removes part of bug 391002: it does not remove attributes anymore after removing broadcaster, and does not notify document anymore.

(In reply to comment #13) >does not notify document anymore. Why not?

Sorry, it was a mistake. That patch do not remove attributes, but still notifies document (after layout is initialized) if one is set.

This bug bugs me. My investigation: https://bugzilla.mozilla.org/show_bug.cgi?id=391002#c24 ?

Checking in content/xul/document/src/nsXULDocument.cpp; /cvsroot/mozilla/content/xul/document/src/nsXULDocument.cpp,v <-- nsXULDocument.cpp new revision: 1.804; previous revision: 1.803 done Checking in content/xul/document/src/nsXULDocument.h; /cvsroot/mozilla/content/xul/document/src/nsXULDocument.h,v <-- nsXULDocument.h new revision: 1.204; previous revision: 1.203 done Checking in content/xul/document/test/Makefile.in; /cvsroot/mozilla/content/xul/document/test/Makefile.in,v <-- Makefile.in new revision: 1.6; previous revision: 1.5 done Checking in content/xul/document/test/test_bug391002.xul; /cvsroot/mozilla/content/xul/document/test/test_bug391002.xul,v <-- test_bug391002.xul new revision: 1.2; previous revision: 1.1 done RCS file: /cvsroot/mozilla/content/xul/document/test/test_bug414907.xul,v done Checking in content/xul/document/test/test_bug414907.xul; /cvsroot/mozilla/content/xul/document/test/test_bug414907.xul,v <-- test_bug414907.xul initial revision: 1.1 done

Looks good on Mac using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021204 Minefield/3.0b4pre. Will check on Windows and then verify.

verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008021204 Minefield/3.0b4pre.