Closed Bug 80281 Opened 24 years ago Closed 24 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: 24 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: 24 years ago → 24 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: