User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3b; MultiZilla v1.1.34 (c)) Gecko/20030214 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3b; MultiZilla v1.1.34 (c)) Gecko/20030214 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3b; MultiZilla v1.1.34 (c)) Gecko/20030214 Sidebar tab headers and contents not displayed when opening SB for the first time with mouse handle. I didn't find a bug report related to current 1.3b nightlies about this, so here we go. Reproducible: Always Steps to Reproduce: 1. Open Mozilla browser with a newly created profile 2. close the sidebar with the little mouse handle 3. exit Mozilla 4. open the browser again with your new profile 5. open the Sidebar with the little mouse handle Actual Results: The pane content doesn't build up. There are only the title "Sidebar" in the left top corner and in the top right one the Tab-pulldown and the close symbol. You have to exit and reopen the sidebar using F9 to make it work. Subsequent open/close using the little handle then will work for this session. Expected Results: Display of all available Sidebar tab headers and show content of currently active tab. Bug is still present in 20030221 on OS/2 and confirmed on Win98 as well by someone else in the NGs.

*** Bug 195214 has been marked as a duplicate of this bug. ***

i too always get an empty sidebar when opening with grippy first time. (Linux) If i open a second window it tends to be ok. Or hitting F9 twice will fix it. Bug 116520 and bug 180438 are about the same thing. I think this bug is quite old - i've been seeing it for years now. Do you see any js errors in console when this happens?

Under windows things used to work quite nicely for a while though. I have been off-line for a few weeks so i don't know when this started to go wrong, but noticed it earlier this week as well.

AFAIR this problem occured recently, but I'm not sure if it was present already in the 1.3b Release version or appeared shortly after. The js console doesn't show any activity during this process.

I'm using build id: 2003022810 (the newest as of 2/28/03) and I'm still experiencing this bug. Chris

I've checked back and this bug was present in 1.3b Release and is still present in Win32 nightly 20030301

Regarding comment #2: Warning: reference to undefined property sidebarObj.collapsed Source File: chrome://communicator/content/sidebar/sidebarOverlay.js Line: 1491

This bug has been reported @ http://bugzilla.mozilla.org/show_bug.cgi?id=119975 and is therefore a duplicate to Bug 119975

I doubt that this is really a duplicate of bug 119975. That bug seems to concern what happens after the "windows integration dialog" displays (for setting as the default browser?) This bug happens even if no dialog is displayed first. I know there are some other symptoms also listed in that bug, but most of them don't seem to match this situation either, as far as I can tell.

I am seeing this bug too, with a new profile or my normal one. Mozilla 1.3 nightly 20030305, on Win 2000 Pro, SP3. Here are a couple of details I noticed. The blank sidebar only happens on the first browser window in which you attempt to "unminimize" the sidebar with the little mouse grip/handle. Subsequent browser windows will display the full sidebar contents. If you close all browser windows, the content will again be missing on the first new browser window in which you attempt to "unminimize" the sidebar. It doesn't seem to matter whether or not other windows like mail/news or composer are open (i.e. you don't have to close out of Mozilla completely in order to reset things and see the blank sidebar again. You just have to close out of all browser windows. If you select a new tab on the tabs pulldown menu, all tabs appear. If you deselect a selected tab on the tabs pulldown menu, the sidebar contents do not appear. Also, regarding comment #2, I got the following JavaScript error while playing around with this stuff, although I cannot reproduce it now (I can still reproduce the bug behavior itself): Error: sidebarObj.panels has no properties Source File: chrome://communicator/content/sidebar/sidebarOverlay.js Line: 1494

I am seeing this but quite as described. When I open on relaunch - the sidebar appears 'gray' until I finish dragging mouse handle- let go and it fills in with proper tabs. Second open using same method shows all proper tabs immediately

Regarding comment #11: Your method doesn't work for me, here it's _only_ pressing F9 twice. Now on Mozilla 1.4a Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4a; MultiZilla v1.4.0.1) Gecko/20030312

Regarding comment #11: When I click and drag the little mouse handle, the sidebar contents show when I release. When I click the little mouse handle to open it without dragging, the sidebar contents never show (as long as the other conditions in comment #10 are meant.)

I see this: If sidebar was visible but closed when i exit'ed mozilla: After a new startup, no tabs display when i click the grippy to open sidebar If sidebar is visible AND open when i shut exit mozilla: After new startup, the tabs in sidebar are visible and OK If sidebar is NOT visible (not activated with "view") when i shut down Mozilla, selecting View->Sidebar (or F9) will usually enable sidebar in usable state on first go.

*** Bug 197292 has been marked as a duplicate of this bug. ***

I can reproduce same results as comment #13 F9 twice always works for me too

*** Bug 197618 has been marked as a duplicate of this bug. ***

I open the sidebar with the mouse handle and it stays blank; if I now select a new tab or unselect and reselect one, all tabs are visible again.

*** Bug 197837 has been marked as a duplicate of this bug. ***

*** Bug 197970 has been marked as a duplicate of this bug. ***

This sounds like a duplicate of bug 187186. The behavior described in comment 10 is happening for me too in build 2003030308.

*** Bug 187186 has been marked as a duplicate of this bug. ***

*** Bug 168998 has been marked as a duplicate of this bug. ***

*** Bug 180438 has been marked as a duplicate of this bug. ***

*** Bug 176424 has been marked as a duplicate of this bug. ***

*** Bug 198322 has been marked as a duplicate of this bug. ***

*** Bug 198495 has been marked as a duplicate of this bug. ***

I havent ever gotten this bug before, on my windows 98 system it is unique to Mozilla 1.3

*** Bug 198884 has been marked as a duplicate of this bug. ***

*** Bug 199403 has been marked as a duplicate of this bug. ***

*** Bug 199855 has been marked as a duplicate of this bug. ***

Seeing it on 1.4a nightly: Mozilla 1.4a Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401. I've also seen this behavior on Mac OS X and Linux.

*** Bug 200322 has been marked as a duplicate of this bug. ***

*** Bug 200325 has been marked as a duplicate of this bug. ***

*** Bug 200411 has been marked as a duplicate of this bug. ***

*** Bug 200678 has been marked as a duplicate of this bug. ***

navtriage: nsbeta1+/adt2

I get this same bug too. I leave my sidebar opened, but hidden on the left side. Whenver I close Mozilla down and reopen, if I unhide the Sidebar it is empty. I have to close and reopen the Sidebar using F9 or the menu option before it will display any contents. This is on a Windows XP Pro machine running Mozilla 1.3.

I've not been able to test the patch - I'm not sure I have the technical abilities needed to apply it :-) But I look forward to seeing this back in a released build. v1.3.1 =:-)

Response to Comment #39 : Mozilla/5.0 (OS/2; U; Warp 4.5; de-AT; rv:1.3; MultiZilla v1.4.0.3f) Gecko/20030313 Yippieh, this finally does the trick for me :-) Thanks a lot.

Comment on attachment 120032 [details] [diff] [review] patch sr=jag

Comment on attachment 120032 [details] [diff] [review] patch r=sspitzer

resolving

*** Bug 201623 has been marked as a duplicate of this bug. ***

verified mozilla build 2003041108

Wow, this (or bug 125197 or bug 166912, but I guess it's this one) increased xulwinopen on luna by about 30%!! (if I'm able to read everything correctly) Don't know if various windows are measured or only the browser window for this test, so if the AB window is also on the list it might have been bug 125197... comet went up by about 5%, the others were not affected. What does that mean?

This also regressed Ts.

reopening

ok, that wasn't the right fix. i thought i had caused this regression but it turns out to be something else. this is a patch backing out my checkin for this bug, also backing out fix to bug #186515 which caused this regression, and removing the problematic (and unnecessary) line in sidebarOverlay.js, which fixes both of these bugs.

Either I made some mistake by applying the changes of attachment (id=120343)to comm.jar, or it is breaking the appearance of the sidebar contents again on Mozilla/5.0 (OS/2; U; Warp 4.5; de-AT; rv:1.3; MultiZilla v1.4.0.3f) Gecko/20030313. Btw, does it have to be applied in addition to the first fix (that's what I did) or to the original, unmodified sidebarOverlay.js?

Weird, it seemed to be some kind of a one time glitch, when the sidebar didn't want to populate after applying fix #2. For several subsequent restarts of Mozilla the sidebar performed correctly now. So I guess it's now also still fixed for me :-)

Comment on attachment 120343 [details] [diff] [review] patch sr=jag

resolving txul back to normal now

*** Bug 202404 has been marked as a duplicate of this bug. ***

verified with build 2003041704

*** Bug 202467 has been marked as a duplicate of this bug. ***

It's weird, but sometimes it doesn't want to open.

*** Bug 203553 has been marked as a duplicate of this bug. ***

This seems to be back in the 2003042708 build for Mac OS X. It was fine with the 20030423 build.

*** Bug 203821 has been marked as a duplicate of this bug. ***

*** Bug 204472 has been marked as a duplicate of this bug. ***

*** Bug 204620 has been marked as a duplicate of this bug. ***

Since the fix for this bug has landed, sidebar has started having redraw issues on seocond opening (bug 203037).

*** Bug 204353 has been marked as a duplicate of this bug. ***

*** Bug 203148 has been marked as a duplicate of this bug. ***

*** Bug 205993 has been marked as a duplicate of this bug. ***

*** Bug 209143 has been marked as a duplicate of this bug. ***

I had the same problem the thirdish time I opened Moz with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Also adding comment to <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=209143">Bug 209143</a> which was my original report but was marked as duplicate.

i'm seeing this again in 1.4 final.

*** Bug 205588 has been marked as a duplicate of this bug. ***

*** Bug 205116 has been marked as a duplicate of this bug. ***