Closed Bug 199178 Opened 18 years ago Closed 18 years ago
Bookmarks folder in personal toolbar is empty
Build 2003032504 WinXP It seems that it is a side-effect of the landing of the bookmarks branch, the bookmark folder in the personal toolbar is empty. I can still see my bookmarks in the sidebar, the menu and with CTRL+B
noticed this 3/25 also- nominating
adding useless-UI keyword. I didn't see a keyword for proposing this as a blocker for 1.4a but I think that this is a serious usability bug, even for an alpha release.
I do not see this with 2003032612 on Win2k, but I'd like to cc Jan Varga as one of the bookmark branch people so they know about it. (Sorry if that's inappropriate.)
yes I see it too
Assignee: ben → varga
QA Contact: kasumi → petersen
This is back to normal in build 2003032808
false alert, after exiting/restarting Mozilla, bookmarks are gone again :-(
I think that this is the result of an incompatibility with the prefbar.
*** Bug 200026 has been marked as a duplicate of this bug. ***
from bug 200026, on Mac OS X, the Bookmarks menu is nearly empty when there are no open windows (only a menubar).
OS: Windows XP → All
Hardware: PC → All
*** Bug 200183 has been marked as a duplicate of this bug. ***
The bug definitly *is* related to the "PrefBar". After Uninstalling (see the FAQ of PrefBar), every Problem with the Bookmark Folder is gone. Still, why does it work well for every other (previous) version of Mozilla? Anything changed which influences toolbar-xpis or something like that?
Ok, somebody finally let me know about this bug. I can probably try to work on a fixed prefbar sometime next week or the week after if we can figure out what exactly the prefbar is doing to cause this. If no one has the time I can look into it in a few weeks when I get some more free time.
*** Bug 200645 has been marked as a duplicate of this bug. ***
Reproduceable testcase: Ok, i've narrowed it down to definetly not being a bug in the external code by us, but even a null(empty) overlay onto the toolbars (as shown below) will break the Bookmarks Menu in the Personal Toolbar. Something has changed in the overlay code.. We need some experts here. <?xml version="1.0"?> <overlay xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <toolbox id="navigator-toolbox"> </toolbox> </overlay>
Priority: -- → P1
Target Milestone: --- → mozilla1.4beta
As an aside, i vote the Bookmarks menu/Button be removed totally from the Personal Toolbar since it will increase the real-estate available on the Personal Toolbar for personal bookmarks, and it is redundant since we already have a Bookmarks Menu on the Top most menu which works just fine.
Ummm... 1) you can already remove it using the preferences 2) ALL bookmarks in the personal toolbar are redundant: all are also in the bookmarks menu. And "Reload" is in context menu and in the main toolbar. And so on. Yeah, I also removed it a while ago, but only after liking it for a long time.
Yes, you're right. I didn't see that preference. You can disable the Bookmarks menu. But the bookmarks for the personal toolbar are not redundant or else you are sayng that we should remove the personal toolbar completely ? Anyhow, this is detracting from the main issue - which is that overlays are broken.
*** Bug 201449 has been marked as a duplicate of this bug. ***
I believe this bug should be closed as a dup of bug 101131 that is awaiting a checkin imminently. This was due to bug 66919.
I think, this is the real fix. We need to defer the hookup of template builders until a document is fully resolved, that is, all content is merged with overlays. I also cleaned it up a bit.
Comment on attachment 120716 [details] [diff] [review] real fix I think hyatt should take a look at this. I could sr= if bryner doesn't want to.
Attachment #120716 - Flags: review?(jaggernaut) → review?(hyatt)
hyatt, see bug 101131 for more details
This patch shouldn't impact Txul, I tested on Linux It seems it's even a bit faster, but that's probably a noise.
Sure, I'll sr this once someone familiar with the code has r='d it. cc'ing Ben.
FYI, the new pnhtoolbar also make this buf happen
Seems ok to me. Is there ever actually a case where xblService is null?
I see a similar construct in nsSplitterFrame.cpp
Comment on attachment 120716 [details] [diff] [review] real fix hyatt says r=hyatt
Attachment #120716 - Flags: review?(hyatt) → review+
Attachment #120716 - Flags: superreview?(bryner) → superreview+
checked in we got an extra bonus, Txul dropped down by 4.6t% on beast and others also do better
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Ummm... Jan, I don't want to disappoint you, but Txul was 313ms already several times before your checkin. It only jumed up to 328ms in the build during your checkin to revert to "normal" afterwards (as it did several times before). Seems like those are discrete values.
I've been seeing this bug with these exact symptoms for a couple of days now -- unfortunately the patch attached to the bug has not helped for me.
Andreas, well, it definetely improved Txul slightly on comet and luna. I already mentioned that I see a little improvement in Txul, but I thought it's only a noise. Adam, what additional overlay/extension are you using in your build ? I'm asking because this did fix the problem in commercial builds which use an additional PT overlay.
I don't /think/ that I'm using any unusual overlays or extensions, unless Calendar counts. I'll see if a fresh profile helps.
Then you're seeing a different problem. I just installed http://gehry.cs.kent.edu/~collard/mozilla/xulapps/prefbar.xpi and everything worked as expected.
A fresh profile doesn't help. I'm not claiming that my symptoms have the same root cause as those fixed by the attached patch, I'm claiming merely that I'm seeing the same symptoms described in this bug report and that those symptoms are still there. :(
Well, several people reported here that it's related to prefbar. I suggest to file a new bug and describe exactly what you're seeing.
(A clobber-build seems to have fixed it!)
glad to hear that, sorry for the SPAM
Verified in the 2003-04-22-08 Macho and Win32 trunk build.
Status: RESOLVED → VERIFIED
*** Bug 203726 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.