Closed Bug 204022 Opened 23 years ago Closed 23 years ago

Personal Toolbar is blank when Mozilla loads

Categories

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

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4final

People

(Reporter: jgleigh, Assigned: janv)

References

Details

(Keywords: regression, Whiteboard: [adt1] [ETA 2003-05-22])

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030430 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030430 My personal toolbar folder has several items in it, but now when Mozilla starts up the personal toolbar is blank without any items on it. The items still show up in the Bookmarks pulldown menu. Opening a new window will correct the strange blank behavior, but the original window is still messed up. Reproducible: Always Steps to Reproduce: 1. Start Mozilla 2. Notice how the personal toolbar is blank 3. Open a new window and notice how the toolbar re-appears This just started when I downloaded the 4/30 build. Didn't see it with my previous one which I believe was around 4/18 or so. Also works correctly back in 1.4a.
This happens in both the Classic and Modern themes. Also interesting is that if you run a previous version, say 1.4a, and then come back to this build, the toolbar will work the first time you run the 1.4b build, but subsequent launches will revert to the blank behavior. Seems like the 1.4b build is writing something back to a prefs file and causing this issue.
WorksForMe using FizzillaMach/2003-04-25-08-trunk. Jeff, you might try some builds between 0425 and 0430 and determine which day this started on.
Confirmed using FizzillaMach/2003-05-01-08-trunk. Related to bug 202630?
Status: UNCONFIRMED → NEW
Ever confirmed: true
MacOS -> Jan
Assignee: chanial → varga
Confirmed with the 2003-05-01 builds (on Mac OS X). It worked fine with 2003-04-28. When I saw it, I tried deleting the XUL.mfl file, and that fixed it ... until the next restart.
Note that you can still add and delete bookmarks - the changes will be saved in the bookmarks.html file. So it must be in the prefs or in the XUL.mfl file (since removing that fixes it temporarily.
Bug introduced between FizzillaMach/2003-04-29-08-trunk and FizzillaMach/2003-04-30-03-trunk. Check-ins: <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Change+Size&hours=2&date=explicit&mindate=04%2F29%2F2003+12%3A08%3A00&maxdate=04%2F30%2F2003+08%3A53%3A00&cvsroot=%2Fcvsroot>. Maybe bug 192014?
Flags: blocking1.4b?
Summary: personal toolbar is blank when Mozilla loads → Personal Toolbar is blank when Mozilla loads
(Note that when you run a different build, the problem only manifests on the *second* launch.)
Well, attachment 122043 [details] [diff] [review] (from bug 192014) will call hiddenWindowLoadBookmarksCallback() after a small delay. I'm willing to bet that this happens *after* the toolbar data-structures is loaded. I noticed that the toolbar will be correctly loaded when the XUL.mfl is missing. When the happnes, Mozilla starts up slower, because it can't read that cahce-file, and has to built a new one. Maybe we don't see the bug i this case, because the timing is changed.
Status: NEW → ASSIGNED
Depends on: 204211
I'm willing to bet that the patch in bug 204211 is going to fix this bug also.
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
I see this on Mac OS X (not sure why that should be a separate bug from Bug 202630) and in my case everything was working fine until I used the "Switch profile..." menu for the first time. When I came back to my original profile, the personal toolbar was blank except for "Home" and "Bookmarks" at each launch, until opening a second window. At the time I believe I was using the 4/23 build, maybe 4/25 but it was about a week old before I first saw the problem and downloaded a newer build (5/01).
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4+
Adding keywords
Keywords: nsbeta1, regression
Is this really a regression? There is no previously-filed bug that describes this behavior that can be said to have regressed.
I 'm calling this a regression since this feature of displaying user bookmarks/folders on the personal toolbar had worked on earlier milestones. It's basically not working consistantly on the current Macho build.
If you elect to hide the personal toolbar, you can quit out and when you return and elect to show it again, it will display as expected. This only works until browser is quit again.
*** Bug 204885 has been marked as a duplicate of this bug. ***
My apologies in not finding 204022 when I first reported 204885. I note the following: When I open another browser window, the personal toolbar is not corrected. When I start an earlier browser version (1.4a), the personal toolbar remains gone. When I return to 1.4b, the personal toolbar remains gone. In all cases, the default first entry (Bookmarks) is present.
*** Bug 204943 has been marked as a duplicate of this bug. ***
Noticed the following curious behavior - just updated to build 2003050808. I have mozilla set to start both navigator and mail at start up. Upon first startup mail loads first, then navigator (when startup is finished, navigator is on top). Subsequent startups are reversed (navigator loads first, then mail; when startup is finished mail is on top). Under the first scheme, the personal toolbar is okay. Under the second it is blank. If you start mozilla with just mail first, then open a navigator window, the toolbar is okay. Maybe (?) my memory is bad, but it seems to me that previous versions of mozilla (that did not exhibit this bug) opened the "good" way (mail first, then navigator).
*** Bug 204984 has been marked as a duplicate of this bug. ***
*** Bug 205002 has been marked as a duplicate of this bug. ***
I was noticing this in trunk builds myself. It also made it's way into 1.4b.
*** Bug 205037 has been marked as a duplicate of this bug. ***
*** Bug 205051 has been marked as a duplicate of this bug. ***
*** Bug 205059 has been marked as a duplicate of this bug. ***
I can confirm the "disappearing personal toolbar" links on two separate systems. MacOSX 10.2.6, Mozilla 1.4b. Doing a clean reinstall of Mozilla did not help. After the next restart the same problem occured. Trying to create a new Personal Toolbar folder and/or "reassiging" it from the manage booksmarks area did not solve the problem.
*** Bug 205089 has been marked as a duplicate of this bug. ***
*** Bug 205134 has been marked as a duplicate of this bug. ***
*** Bug 205214 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.4beta → mozilla1.4final
*** Bug 205249 has been marked as a duplicate of this bug. ***
Blocks: 205378
adt: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
*** Bug 205438 has been marked as a duplicate of this bug. ***
What's strange is that when I receive the emailed alert for changes to this bug report, then click the link that takes me to the page I'm writing in now, the new window shows the toolbar bar items as they should be. After this action, other new windows also show the toolbar correctly. However, quitting and reloading Mozilla (1.4b) reverts to the blank toolbar, and new windows *don't* correct the problem. Is anyone else using BookIt? I wonder if there if the bug is in the way BookIt codes it's toolbar bookmarks....
In reply to William: I do use bookit, but I tried trashing all my mozilla prefs and starting with a fresh install, creating a new profile. The problem persists with this new bookmark file created by Mozilla itself, so it's unlikely anything to do with Bookit. It's also known that this bug only affects the inital Mozilla window, and that any new windows you create have a normal toolbar. So when you click on a link in Mail and get a new mozilla window it's no suprise it looks normal.
In response to Adrian: As noted previously, for me, at least, the absence of the Personal Toolbar entries affects ALL windows, not just the first.
I can start moz 1.3 and the toolbar re-appears... then, when I restart 1.4b, everything is fine and personal toolbar stays until I logout.
Per Samir's request: This problem appears to be resolved in varga's tree build (see http://bugzilla.mozilla.org/show_bug.cgi?id=205378. I wasn't able to reproduce this issue using the Macho test build he provided.
If I go to manage bookmarks, the Location tag (that should show a local file path) for the blessed personal toolbar is blank. The folder does have that PT flag set, as shown in the properties window, and the menu item to bless is greyed. If I drag each toolbar item in the manage window back onto it's parent folder icon, it reappears instantly on the toolbar. It is gone the next restart, however. But this is for the moment a workaround - do that every restart... build 2003050714. I'll try a new build. Also - if you don't do the re-drag in the manage window, if you force a rewrite of the config (about:config and change something), presto-chango the toolbar is back.
*** Bug 205803 has been marked as a duplicate of this bug. ***
If bug 204211 is too risky for now, shouldn't bug 192014 simply be backed out in order to ship 1.4?
If everything goes well, I'll land the patch for bug 205378 soon. That patch contains a fix for this bug too.
*** Bug 205864 has been marked as a duplicate of this bug. ***
I keep seeing this, and it makes bookmarks look broken.
Priority: P3 → P2
*** Bug 206174 has been marked as a duplicate of this bug. ***
Just wanted to add that I have two profiles: One I use regularly and one created to test a suspected bug. On the first, switching profiles (from and back to) and creating a new window puts the bookmarks back on the toolbar. The second doesn't manifest this problem (with the default bookmarks on it).
*** Bug 206215 has been marked as a duplicate of this bug. ***
*** Bug 205204 has been marked as a duplicate of this bug. ***
*** Bug 206494 has been marked as a duplicate of this bug. ***
*** Bug 206543 has been marked as a duplicate of this bug. ***
*** Bug 206566 has been marked as a duplicate of this bug. ***
Whiteboard: [adt1] → [adt1] [ETA 2003-05-21]
Whiteboard: [adt1] [ETA 2003-05-21] → [adt1] [ETA 2003-05-22]
*** Bug 206667 has been marked as a duplicate of this bug. ***
*** Bug 206694 has been marked as a duplicate of this bug. ***
*** Bug 206828 has been marked as a duplicate of this bug. ***
I tested on Mozilla-trunk(Build ID:2003052307). After first loading Mozilla, items of Personal Toolbar appear. After quitting Mozilla and loading again, Personal Toolbar is not blank. It seems that this bug is gone. Thanks.
I just tested it as well, seems to be working now.
Would someone please explain to me how to locate a specific build, for instance Build ID:2003052307, mentioned in Comment #55 today (23 May)? The FTP site does not list by Build number. Thx.
Looks like it's fixed in 2003052307... to get the latest build, go to: http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/ Download your flavor and surf it!
Well, fortunately, Build 2003052307 was last night's. Personal toolbar glitch is definitely fixed.
RogerWilco: The build number is based on the date it was released. Build ID:2003052307 means 2003-05-23 (not sure what the 07 at the end means, though)
Bug 205378's patch appears to have been checked in early this morning, which is probably why this bug appears fixed in today's build.
Fixed by 205378. Verified in the 2003-05-23-07 Macho trunk build.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified
Status: RESOLVED → VERIFIED
*** Bug 207319 has been marked as a duplicate of this bug. ***
*** Bug 207532 has been marked as a duplicate of this bug. ***
*** Bug 207824 has been marked as a duplicate of this bug. ***
*** Bug 207877 has been marked as a duplicate of this bug. ***
*** Bug 208498 has been marked as a duplicate of this bug. ***
*** Bug 208746 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.