Closed Bug 119975 Opened 23 years ago Closed 15 years ago

Sidebar blank with new profile

Categories

(SeaMonkey :: Sidebar, defect)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.4beta

People

(Reporter: scalkins, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [adt3][driver:asa])

Attachments

(5 files, 1 obsolete file)

Patch that now only rebuilds sidebar if windows integration dialog was shown.
5.31 KB, patch
law
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
Snapshot of how Mozilla looks with regards to this bug
139.48 KB, image/jpeg
Details
After doing as I noted in Comment #58, sidebar finally shows
171.48 KB, image/jpeg
Details
Screen shot of blank/empty side bar
45.49 KB, image/png
Details
Another example of blank or empty sidebar
28.77 KB, image/png
Details 
I only see this on Windows
win32 2002-01-14-09 Trunk

Steps to repro:
1)Launch NS with a new profile (I cancelled activation)
2)When browser appears, look at sidebar

Actual results: The sidebar is missing all default tabs. I can still see test
"My Sidebar", "Tabs" and the Close "x" at the top. 
If I pull down Tabs menu and "remove" a checked tab, all the rest of the checked
tabs will suddenly appear.
Nominating nsbeta1 for bad user experience and non-intuitive workaround.
Keywords: nsbeta1
yes I saw thsi also....I was just gonna file/ask samir about this...

Samir, I can reproduce this with new profile.

the workaround is to click around the tabs and then pof everything
appears..

Tracy, you might have seen this also with today's builds.
not a problem on branch builds...just confirming there..

but still a problem on today's 1/15 trunk. 

workaround is to click on Tabs menu and shose a tab, then
all the tabs appear in the sidebar.

Tracy, are you sure you're not seeing this happen ?
Severity: major → critical
This happens on old profiles as well and has been around for a few days.
*** Bug 120065 has been marked as a duplicate of this bug. ***
This is a fairly visible regression and it'd be nice to see it fixed for 0.9.8
Blocks: 115520
I can't reproduce this per the original steps with a 2002011703 Win2K mozilla
trunk build.  Created a new profile and the sidebar displays fine.  Used an old
profile and the sidebar displays fine too.  Am I missing something or is this
automagically working again?
this seems to be working now...

Suzanne, reopen if you still find it not working...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
I saw this on my win2k box with 2002-01-17-06 build today
Try a "clean install" setup..remove Mozilla profile and .dat files in window
directory and start NS6.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
hrm,if you can't repro this with clean install..maybe it's commercial only?
No, it's not commercial only.  The key to this bug is that if the windows
integration dialog pops up then the sidebar doesn't load after that.
Status: REOPENED → ASSIGNED
Reverting revision 1.420 of navigator.js (fix for bug 87257) fixes this.
Keywords: regression
CC'ing danm after consulting waterson who thinks this could be a problem with
event queues dropping the event that sets in motion the plugging of panels.rdf
into the template that builds the sidebar.  Dan, can you shed some light?  Thanks.
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
Till we figure out why the sidebar wasn't building when the windows integration
dialog pops up I'd like to get this patch in.  This bug has been deemed
important to fix for mozilla0.9.8 by drivers hence the quick fix.

law, please r.
waterson, please sr.
Keywords: patch, review
Why don't we just back out the fix for bug 87257 (for now)?  Surely that's not
critical for this release, or any milestone really.
FWIW, here is some related info, which may or may not be useful to fix the other
bugs I'm going to mention by backing out bug 87257:

after the 1st profile I created, I did see this problem, I then had chosen to
select the dialog to 'No'. After that, I see this didn't happen when creating a
2nd new profile in 1-17-03 and the sidebar did load after creating the 2nd one.
 Then I went into preferences and checked the system setting box to popup,
closed mozilla, and reopened the same profile and the sidebar contents didn't load. 

If you hit F9 twice: see bug 116094, sidebar contents are displayed in browser
again (and F9 for mail/news too). 

as far as the sidebar in mail/news not loading as I reported in my dupe bug
120065, I'm not sure that the mail/news sidebar is exactly affected by this
problem as you see it is not loaded in attachment 64655 [details], and in the problem bug
117130.
Whiteboard: [driver:asa]
Comment on attachment 65557 [details] [diff] [review]
Force the sidebar to build after the windows integration dialog has been dismissed.

r=law

The code looks fine.  But I'm not sure that this isn't just masking a real
problem.

Backing out the fix for bug 87275 might do that, too.  But I think that might
be better because it seems it would have less impact.  Does SidebarRebuild()
cost much?  We're doing that at every window open, even when the checkSettings
all doesn't cause a dialog to display.	Backing out the  other fix only affects
(less severely?) the cases that *do* display the dialog (and that's just once
per user, typically).

Can we simulate that dialog opening by opening another dialog.	E.g., a start
page with a alert() in the onload handler?  That isn't exactly the same thing;
the alert opens at content onload vs. (close to) chrome onload.

Or, a start page on a site requiring authorization (so it puts	up a password
dialog).
If the sidebar has problems in those cases, maybe we need to look harder into
fixing the root problem.
Attachment #65557 - Flags: review+
Yes, I realized this would affect every window open too.  I could change
checkSettings() to return true when a dialog was thrown up and only in that case
rebuild the sidebar.  

Bill, this doesn't affect a page that has an onload handler that throws up an
alert.  So even with the following home page contents the sidebar loads fine:
<html>
<body onload="alert('foo');">
</body>
</html>

Having said that, let me know if you prefer me backing out the fix for bug 87257
or adding in the return param to checkSettings().  At any rate, drivers would
like us to come to a resolution for 0.9.8 as soon as we can.  Thanks.
Comment on attachment 65708 [details] [diff] [review]
Patch that now only rebuilds sidebar if windows integration dialog was shown.

sr=dveditz, pending law's r=
Attachment #65708 - Flags: superreview+
Samir, can we just back out the change to 87275? I'd prefer that for the
Milestone since bug 87275 isn't really critical for the release and this is. 
Comment on attachment 65708 [details] [diff] [review]
Patch that now only rebuilds sidebar if windows integration dialog was shown.

r=law
Attachment #65708 - Flags: review+
FYI, the sidebar in MailNews window is always empty at startup (bug 121215)
For another not fully painted sidebar bug, see bug 121340.
a=brendan@mozilla.org on behalf of drivers for 0.9.8 checkin of attachment 65708 [details] [diff] [review].

/be
can we get this in the branch and trunk now?
Checked in attachment 65708 [details] [diff] [review] to trunk and 0.9.8 branch.
Completed 0.9.8 tasks for this bug.  Over to mozilla0.9.9 for more investigation.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
I'm getting very simular behaviour but on an existing profile. This could be the
same bug, but it's a bit different.

When I startup (26th build or later win2k) the sidebarpanel is blank only
showing the handle of the top sidebar (history in my case) the "my sidebar"
pulldown is empty except for the cusomize and directory items

clicking the history handle once shows the second sidebar handle in my panel,
but not the sidebar. Clicking history again shows a working history sidebar, but
that's as far as I can get.

Showing and hiding the sidebarpanel alltogether makes it worse, now the "my
sidebar" pulldown has disappeared and the 'x" button is less high than it was.

This could be a new bug, or it could be related to thsi one, I'm not sure.

I'm going back to the 25th january build as sidebars work there, and I'm
currently working on an new sidebar of my own (so I need the sidebar panel to be
functional).
I created bug 122027 yesterday to cover the new (to me) problems with the
sidebar and an existing profile. 
this appears to be fixed on the trunk, and I believe Samir noted in blocker bug
122027 comment 15, that this is on the branch too.
Suzzane does this work for you now ?
WFM win2k / 2002012803
Yep, worksforme on win32 2002-01-29-06 Trunk (win 2k)
I should note, I no longer get the "default browser?" dialog with todays build.
Samir, you can resolved this bug now...thanks.
Using NSPR logging and a nifty post-processing perl script from danm, apparently
all posted events are matched by code to handle them.
Samir, does this bug still need more work ? or can we close it out...
Sujay, the underlying problem needs to be investigated still: we only fixed the
symptom and are not sure that the problem may cause similar symptoms to manifest
in other ways. 
Sidebar triage team: -> mozilla1.2, severity: normal, nsbeta1-
Severity: critical → normal
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2
this appears broken again after the dialog comes up, sidebar content is not
displayed in build 2-20 w2k for me.
Clearing nsbeta1- for re-review for high visibility and bad users first
impression of product.
 This reoccurs now when I get the dialog for default browser with a new profile
again.
Win32 2002-02-25-05 Trunk (Win2k)
Severity: normal → critical
Keywords: nsbeta1- → nsbeta1
Suzanne,
The symptoms will be fixed with bug 127113.  This bug tracks the work we have to
do to eliminate the need for SidebarRebuild() when the windows integration
dialog pops up.  Bug 127113 has been nominated and will likely be fixed.  See
also comment 38.  Thanks.
Keywords: nsbeta1 → nsbeta1-
seeing this in 3/1 trunk build....just thought I'd comment because I wasn't
seeing a lot this before...
*** Bug 128656 has been marked as a duplicate of this bug. ***
Not seeing this in Mozilla win32 nightly builds but I am seeing this in NS6.2.2
test build. The sidebar is completely blank, no tabs, no status bar, NOTHING.
Rapid open/close with F9 doesn't work to bring it "back".
Jay, try again with a new profile, launch sidebar, it should work.


Jay,

The key to this bug is that if the windows integration dialog pops up then the
sidebar doesn't load after that. 

Are you experiencing this?

This problem will be fixed in the next release.
Sujay,

Samir did fix the Browser Sidebar with bug 127113, and windows integration
dialog coming up.. so Fixed in 3-22-03 W2k.

for the record here: if anyone brings up Mail/News sidebar blank with new
profile, that is bug 123205..
No longer blocks: 115520
*** Bug 138043 has been marked as a duplicate of this bug. ***
*** Bug 140139 has been marked as a duplicate of this bug. ***
sometimes the sidebar is completely blank for me. sometimes it loads. i dont
know how to reproduce it. it appears random for me. it doesnt appear to have
anything to do with new profiles or integration dialogs for me, since i've been
using the same profile for months and i only have one profile on this machine.
netscape 6 is not installed on this machine btw. im on win2k using nightly 1.0
branch builds (currently 2002051206)
Using x86 linux (ximian).  I also have Netscape 6 (need it to get the
netscape.net email in a reasonble way).  As this user -- PhilLong69 (other users
have a sidebar that works fine), the sidebar is _blank_ with no controls.  F9
again, and the sidbar title, and tabs control shows up, along with the x to kill
the window. BUT when I try to add tabs, with customize sidebar, selecting "Add"
does _not_ add the  tab (any tab) from "Available Tabs" to "Tabs in Sidebar".  I
get a bit further with Netscape 6, (it adds the tabs), but will not let me hit
"Ok" in the dialouge.  So I've got no sidebar :( 

I'm using mozilla 1.0 (latest ximian patch) / Netscape 6 
*** Bug 126661 has been marked as a duplicate of this bug. ***
*** Bug 147832 has been marked as a duplicate of this bug. ***
Nominating cause wallpaper added per comment 20 seems broken now.
Keywords: nsbeta1- → nsbeta1
Nav triage team: nsbeta1+/adt3
Assignee: sgehani → shliang
Status: ASSIGNED → NEW
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [driver:asa] → [adt3][driver:asa]
QA Contact: sujay → gbush
Target Milestone: mozilla1.2alpha → mozilla1.4beta
I'm chiming with having had this bug linger on my end for several 1.3b nightly
builds nows on the Mac OS X (Mach-O) build, currently using Mozilla/5.0
(Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030307

Essentially the sidebar is blank with no tabs showing and the only visible item
beng the sidebar's background (snapshot of what I'm seeing posted)  Completely
removing and reinstalling Mozilla doesn't help.  I did notice this bug had come
up with the introduction of some nighty version of Mozilla 1.3b (damn shame I
don't recall the date) and it's been continuessly compiled in every version of
1.3b's nightly since.

I'm able to end up viewing the tabs within my sidebar going to Mozilla's menubar
and manually selecting View->Show/Hide->Sidebar to hide it and then going back
to these steps and forcing it to show the sidebar which at that point it does.

This bug so I noticed from other bug reports has been replicated in MacOS X
Bug's  Bug 168998 and Bug 176424  In Linux as noted at Bug 180438 In addition,
it was also noted at Bug 165203

Although this is the first bug in which it was reported at ;)

Side note on snapshot: Don't mind the Pinball theme (found at
http://themes.mozdev.org/themes/pinball.html or the Yahoo Companion under the
URL bar (found at http://mycroft.mozdev.org) I did try to get sidebar to show
without either [although it shouldn't play any part anyway] several times and
yet to no avail.
Comment on attachment 116658 [details]
Snapshot of how Mozilla looks with regards to this bug

In relation to Comment #58
Shuehan,

This seems to be working today in Mozilla builds (and NS also) with new
profiles- not sure why...have installed on all platforms (3/11 builds) and ran
with new profiles.  Sidebar showing in all.
OS: Windows 2000 → All
Hardware: PC → All
I still see empty sidebar on 3/14 nightly - but only for first few profiles
used- F9 brings up the active sidebar.
(Excuse the stumbleupon toolbar.)
I've just reproduced the blank sidebar problem twice for the same time on 1.3
(Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312).  

I open the application with the sidebar closed (drag triangles are visible, but
sidebar closed).
I click on the triangles and the sidebar opens empty or blank.

If I leave the sidebar closed when I quit the browser and then open the
application again, the sidebar will be refreshed and display whichever tab has
been selected.

One thing that is important to note is that I have seen the empty sidebar
behavior on Linux as well in 1.4a.
Hmm, I'm not sure if it's really this bug, because it seems to be a faily recent
regression that sidebar comes up empty on existing profiles, so I've duped the
relevant bugs against bug 195213, which had the biggest CC list of those newer
reports I found.
I just hope the issue can get resovled some time soon...
*** Bug 165203 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
I am still seeing this bug with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.4a) Gecko/20030401.
I had the same issue with 1.3, as well.
I completely uninstalled Mozilla 1.3 before installing 1.4a.  I did not,
however, delete my profile.
F9, F9 brings the tool bar back.  But closing all Mozilla instances and starting
one up causes it to disappear again.

I believe bug 177191 is a dupe of this very annoying bug.

*** Bug 177191 has been marked as a duplicate of this bug. ***
Been noticing now for a couple of weeks daily on their nightlies that this bug
can not be replicated on Mac OS X, tried it moments back on all four of my
Apples running OS X with Moz 1.4rc1 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; en-US; rv:1.4) Gecko/20030529) and once more in this release (and not a
nightly ;) ) the bug did not resurface.  Can anyone else running Apple OS X
attempt to replicate it for as far on my end if it has been corrected (least on
the Apple OS X version), then platform wise Apple and OS wise Mac OSX should be
removed from the Hardware/OS list with regards to this bug.
This bug only affects me if Mozilla (1.4 rc2) is completely uninstalled and
reinstalled.
This bug only affects me if Mozilla (1.4 rc2) is completely uninstalled and
reinstalled, but then it stops being blank if I deactivate a sidebar and then
activate it.
I got this bug consistently until I started trying the varying testcases stated
in these bugs (Bug 195213, Bug 212205, Bug 119975). Now the Sidebar works and I
can't get it to stop working properly.

Perhaps this is related to the "corrupt localstore.rdf" bug?

I'm happy to keep my working Sidebar in the meantime... .
*** Bug 212205 has been marked as a duplicate of this bug. ***
*** Bug 213723 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: shliang → nobody
Priority: P2 → --
QA Contact: agracebush → sidebar
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: