Closed Bug 199178 Opened 21 years ago Closed 21 years ago

Bookmarks folder in personal toolbar is empty

Categories

(SeaMonkey :: Bookmarks & History, defect, P1)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: pascalc, Assigned: janv)

References

Details

(Keywords: useless-UI, Whiteboard: [adt1])

Attachments

(1 file)

real fix
11.00 KB, patch
janv
: review+
bryner
: superreview+
Details | Diff | Splinter Review 
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
Keywords: nsbeta1
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.
Keywords: useless-UI
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
Nav triage team: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
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.
Status: NEW → ASSIGNED
Attached patch real fix — — Splinter Review 
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.
Attachment #120716 - Flags: superreview?(bryner)
Attachment #120716 - Flags: review?(jaggernaut)
Blocks: 101131
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: 21 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. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: