Bookmarks icon is missing text when in Customize Toolbar mode

VERIFIED FIXED in mozilla1.9beta4

Status

()

defect
VERIFIED FIXED
12 years ago
4 months ago

People

(Reporter: marcia, Assigned: arno)

Tracking

({regression})

Trunk
mozilla1.9beta4
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

Posted image Screenshot
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.
OS: Mac OS X → All
Hardware: PC → All
Posted image Screenshot
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
Duplicate of this bug: 414944
> 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.
Attachment #301007 - Flags: review?(neil)
(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.
Attachment #301007 - Attachment is obsolete: true
Attachment #301026 - Flags: review?(neil)
Attachment #301007 - Flags: review?(neil)
Attachment #301026 - Flags: review?(neil) → review+
Attachment #301026 - Flags: superreview?(jst)
Duplicate of this bug: 415421
This bug bugs me.

My investigation:
https://bugzilla.mozilla.org/show_bug.cgi?id=391002#c24 ?
Duplicate of this bug: 415939
Attachment #301026 - Flags: superreview?(jst) → superreview+
Attachment #301026 - Flags: approval1.9?
Component: Theme → DOM
Keywords: regression
Product: Firefox → Core
QA Contact: theme → general
Assignee: nobody → arenevier
Flags: blocking1.9?
Attachment #301026 - Flags: approval1.9? → approval1.9+
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
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
Blocks: 414846
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.
Status: RESOLVED → VERIFIED
Duplicate of this bug: 417254
Duplicate of this bug: 420672
Duplicate of this bug: 415268
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.