Closed Bug 195213 Opened 21 years ago Closed 21 years ago

Empty Sidebar when opening with the little handle for the first time

Categories

(SeaMonkey :: Sidebar, defect)

Product:
SeaMonkey
Component:
Sidebar
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: wolfi, Assigned: shliang)

References

Details

(Whiteboard: [adt2])

Attachments

(2 files)

patch
1.64 KB, patch
sspitzer
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
patch
1.87 KB, patch
jag+mozilla
: superreview+
Details | Diff | Splinter Review 
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sujay → gbush
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. ***
Flags: blocking1.4b?
Keywords: nsbeta1
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
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [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.
Attached patch patch — — Splinter Review 

    
  

        Attachment #120032 -
        Flags: superreview?(jaggernaut)

        Attachment #120032 -
        Flags: review?(varga)

    
    

    
  
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

        Attachment #120032 -
        Flags: superreview?(jaggernaut) → superreview+

    
    

    
  
Comment on attachment 120032 [details] [diff] [review]
patch

r=sspitzer

        Attachment #120032 -
        Flags: review?(varga) → review+

    
    

    
  
resolving
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
verified mozilla build 2003041108
Status: RESOLVED → VERIFIED

    
    

    
  
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
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.

    
  

        Attachment #120343 -
        Flags: superreview?(jaggernaut)

        Attachment #120343 -
        Flags: review?(sgehani)

    
    

    
  
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

        Attachment #120343 -
        Flags: superreview?(jaggernaut) → superreview+

    
    

    
  
resolving

txul back to normal now
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
verified with build 2003041704
Status: RESOLVED → VERIFIED

    
    

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

    
  
Flags: blocking1.4b?

    
    

    
  
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. ***

        Attachment #120343 -
        Flags: review?(sgehani)

    
    

    
  
*** Bug 205116 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: