Closed Bug 80281 Opened 23 years ago Closed 23 years ago

Available Tabs in Customize Sidebar are blank

Categories

(SeaMonkey :: Sidebar, defect, P1)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED INVALID
Milestone:
mozilla0.9.1

People

(Reporter: sujay, Assigned: matt)

References

Details

(Whiteboard: no eta yet.)

Attachments

(2 files)

This fixes the problem for me
1.47 KB, patch
Details | Diff | Splinter Review
Attached a screenshot of customize sidebar box
11.75 KB, image/gif
Details 
using 5/11 build of netscape

1) launch netscape
2) open sidebar
3) click on Customize Sidebar

look at content on the left side of this window under Available Tabs.
It is practically empty. I should load up content/directories to add
tabs.

But if you relaunch netscape with a new profile, then this left
side loads up fine.

Any ideas Matt on this one?

Tracy and Todd have run into this problem also...
Wait a second, I tried with new profile and I still get blank left side
for Available Tabs.

Is this window served up by Netcenter? maybe thats causing the flakiness..
Summary: Available Tabs in Customize Sidebar are blank → Available Tabs in Customize Sidebar are blank
okay rechecking......

.....yep seeing that also....left side selections gone again.  what's up with 
this??
nominating nsbeta1, taking the liberty of plussing and scheduling to 0.9.1 -
vishy, paul, please let me know if you disagree.  This makes the Sidebar pretty
much seem broken.
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.1
Matt - any investigation on why this is happening? 
nav+pdt triage: yes we've got to have this for m0.9.1. reassigning to Ben.
Assignee: matt → ben
nav triage team:

Really need to this for beta, marking priority p1.
Priority: -- → P1
Ben can you add status and eta for this bug? 
This fixes the problem with the content of the right-hand view being cropped too 
eagerly, and seems to magically fix the problem of the left hand view not 
displaying. Maybe some weird interaction going on. 

A couple of window creation flag tweaks while I'm here. More on that later.
Status: NEW → ASSIGNED
Ben - can we get this completed and in today?
Whiteboard: fix in hand, need r/sr
r=matt
*** Bug 81977 has been marked as a duplicate of this bug. ***
sr=blake
Whiteboard: fix in hand, need r/sr → ETA: check in this evening (05/21)
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
okay it looks fixed in today's 5/23 build, but I'm still gonna keep
this bug on my radar...

verified in 5/23 build..

Tracy, do you concur?
no, I'm still seeing just one folder(Recommended) available on the left side and 
it only shows the ">" 
sorry we have to reopen this one...its just doesn't work sometimes..
Is it server related? TRacy Walker also confirmed this inconsistency.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: ETA: check in this evening (05/21) → reopened
Jong, Edmundo, is this a server-side issue?  We really need to fix this quickly
- it is a beta stopper for us.  Can you investigate?
Don't believe this is a server-side issue, but will verify again.  I've 
experienced this problem on certain builds, on a random basis.  I'm currently 
using 5/22 build and it's working correctly.
I was using Netscape 6.0 today for a bit and notice that this same problem
exists.  This leads me to believe that it is more likely a server side problem,
and is critical to fix as it could potentially be affecting current Netscape 6
users.
The original problem was a tree/display issue and this has been fixed. There 
could be latency issues, but that isn't a FE issue. 
This still doesn't work for me on today's build.  This is a beta stopper - where
are we with this?
worksforme with 052404 build on win2K, linux and mac.  
matt - since this is hard to reproduce, can you try on Todd's machine and see
why this is happening? if neccessary, we shd install a debug build on todds
machine and debug it there. thanks, Vishy
Assignee: ben → matt
Status: REOPENED → NEW
Works for me today, using the same build that it didn't work on yesterday. 
Again, this makes me think server-side, but who knows.  The only problem is that
the ordering is wrong.  I believe the list should start with recommended -
Kevin, what's the proper order?
Gonna get Matt and our Production Engineer who edits/pushes the RDF file 
together on Tuesday and take a look at this.
Using US Windows 98, Daily Build 05.24.04

--With an *old* profile, I get *bad* result
--With a *new* profile, created with the above Daily Build, I get a *good* 
result
I'm at home using 6.0, have not installed any later builds on this machine, and
I am seeing this problem, which means that anyone who downloaded 6/6.01 is
likely experiencing this intermittently as well.  We need to run this to ground
quickly.
sujay - do you have any update to this?
Still looking into this.  I'm going over to work with Ops now and see what's 
going on from that perspective.
my update is that I still see this problem from time to time...
i pulled down a copy of the allpanels.rdf to debug and changed my pref to point 
to the local copy.  Everything works fine by doing this.  Reverted to the server 
copy and now everything looks fine.   Still debuging to try to find the problem.
did some more work on this.  This problem seems to happen once in a while.  
Mostly on new profiles.  It seems that once it starts working it will continue 
to work.  I'm going thought the profile differences to see what is different.
Just wanted to update folks that I'm still investigating this.  Everything looks 
good from Ops point of view.  Syntax of files looks good, too.  Reproducibility 
is a big problem.  Was working for me fine for the past week or so, then 
re-booted yesterday and customize sidebar box doesn't even open now...
Whiteboard: reopened → no eta yet.
When first installing a profile about 25% of the time this does not work.
If i move the newcache directory that works to a profile that does not work
everything works fine.  I'm wondering if something is corrupt in the cache or we 
pull down the rdf file wrong and once it is in the cache it will never work.  So 
far I have not isolated the problem.  When i compare the cached version to the 
one on the site it seems to be the same.  Talking to cache guys.
i see now that we are not fetching all-panels.rdf from the netscape.com.
If it is cached then everything works ok but still does not request a fetch.  
Need to investigate why not.
Update:
Start with no cache and no new cache
open customize window
No matter what fetches the all-panels.rdf from the server
If the all-panels items do show up in the customize panel then it will be cached 
and everything will be fine from then on.

If all-panels items do not show up then it the bad copy will be cached and it 
will never show up again.

From that point on we never go to the server to request that page since it is in 
cache.


When i compare the network activitly when the all-panels shows up and doesn't 
show up everything looks the same.

The only difference is that we doen't hit the code path below when we do not 
load correctly:
line 96  
while (links.hasMoreElements()) {
    var folder = 
      links.getNext().QueryInterface(Components.interfaces.nsIRDFResource);
    var folder_name = folder.Value;
    debug("+++ fixing up remote container " + folder_name + "\n");
    fixup_remote_container(folder_name);
  }
adding gagan, gordon to cc list as cache seems involved. 
Isn't all-panels.rdf something we should think about *never* cacheing? Can
someone briefly explain the user benefit of cacheing that specific file? Also,
for us normal folks to try this, can we toggle the cache pref to "Never" to
check this out?
Don't set the cache to "Never", whatever that means.  If you have a problem that 
you think is caused by a cached bad document, then you can clear the disk cache 
by going to the Advanced/Cache preference panel and press the "Clear Disk Cache" 
button.

If you always want to go to the net for this rdf document, you probably need to 
set different flags on the HTTP request.

matt is going to verify if the request is being sent out properly (or if whoever
is making the network request is missing some cache flags -- loadgroup etc.)
IIRC the sidebar doesn't have a loadgroup so things may be going bad becuz of
that... 
OK, this WFM after I did what gordon suggested.
PDT bug triage: is there a simple workaround for 0.9.1? 
http://sidebar-rdf.netscape.com/en-us/sidebar-rdf/0.1/all-panels.rdf is being
served to us with a MIME type of text/plain. We need it to be served as text/rdf
for us to process it correctly. This happens every once in a while, unfortunately.
that sounds like a server problem in that case. edmundo? 
This is _absolutely_ a server problem. FYI, all those millions (cough, cough) of
installed copies of NS6.0 and 6.01 aren't getting any sidebar tabs, either. (If
they're hitting the same server and URL.)
I'm marking this bug invalid.  Chris is totally right and after rechecking my 
network grep output I notice the text/plain in the output that does not work and 
text/rdf in output that works.

works:
HTTP/1.1 200 OK..Server: Netscape-Enterprise/4.1..Date: Thu, 31 May 20
  01 20:28:04 GMT..Content-type: text/rdf.


does not work
HTTP/1.1 200 OK..Server: Netscape-Enterprise/4.1..Date: Thu, 31 May 20
  01 20:21:16 GMT..Content-type: text/plain.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Ok, I'm on the phone with Ops folks now and will work with them using this
latest piece of info.
verified.
Status: RESOLVED → VERIFIED
Ops has updated the mime.types file on all the servers and re-started them.  Not
sure if this if the final solution to the problem...
fyi..same builds that were exhibiting the problem this morning are now working 
fine. 
some of the servers are still not sending out text/rdf

ngrep:
 207.200.86.98:80 -> 208.12.38.241:3778 [A]
 HTTP/1.1 200 OK..Server: Netscape-Enterprise/4.1..Date: Fri, 01 Jun 20
 01 23:31:43 GMT..Content-type: text/plain..Etag: "f6995c30-2-cfb-3aa16

Still show's text/plain.
Ops has found and fixed a couple more items with the all-panels.rdf file.  This
now is working for me with N6.0 and the 2001060120 build.  Anybody else?
This should be fixed now thanks to the joy in ops.  
They have updated the server mimetypes.
Now when that page is opened the page will refresh the cached page from the 
server everyone running 6.01 6.0 and 6.1.
All's well that ends well.

i tested this on 6.01 and 6.1 with bad cached copies.

Thanks!
AWESOME! Vishy
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: