169215 - Sidebar grippy doesn't open/close sidebar after print preview "Close"

Status: NEW

(SeaMonkey :: Sidebar, defect)

Description

[Tracy Walker [:tracy]]

seen when testing for bug 168996 on commercial builds:

windows 2002-09-17-08-trunk
mac os9 2002-09-17-08-trunk

-browser a page
-Close the sidebar by clicking the sidebar grippy
-Select File | Print Preview
-Click "Close"
-Click the sidebar grippy
The sidebar grippy doesn't open the sidebar when clicked on. The little arrows 
in the grippy do switch, but the sidebar isn't opened as expected. Hitting F9 
reopens the sidebar and makes the sidebar grippy usable.

Comment 1

[Paul Wyskoczka]

Updating qa contact to [e-mail]

Comment 2

[Rafael Ebron (:rebron)]

navtriage: nsbeta1-

Comment 3

[Andreas Kunz]

Confirming this for Mozilla. (current nightly)

Additional info:
- The same happens for the window close "X" in print preview
- If the little arrows point to the right and you do the "Print Preview" -
"Close" action again, the sidebar completely disappears (no grippies anymore)
and works after reopening (as mentioned).

Comment 4

[Debbie Kraft]

Confirming for Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040903

Behavior appears to persist since versions from 2003.

Comment 5

[Wayne Mery (:wsmwk)]

related to bug 215643?

Comment 6

[Debbie Kraft]

(In reply to comment #5)
> related to bug 215643?

I don't believe so, since this bug has to do with opening a second instance of
Mozilla Suite.

Additionally, I can confirm that this behavior persists with SeaMonkey 1.0a on
Win 98SE.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> (In reply to comment #5)
> > related to bug 215643?
> 
> I don't believe so, since this bug has to do with opening a second instance of
> Mozilla Suite.
> 
> Additionally, I can confirm that this behavior persists with SeaMonkey 1.0a on
> Win 98SE.

do comment 0, go to view>show>sidebar and it shows selected, click it and stays selected AND opens the sidebar.  So, my guess is print preview turns off something in sidebar before it previews the web page, and opening another page while preview still open messes with the state information that preview uses  to reset sidebar when it closes.  Just a guess.

I reassert bug 215643 and this are the same problem - the component is affected in the same way, even though two sets of slightly different steps cause their respective problems.

In addition, this condition persists across closing and opening of SM - restart SM and grippy is there but not responsive, and sidebar/F9 is not selected.  Despite not selected, so it's not suprising that grippy isn't totally functioning. Is print preview messing with chrome??

As a further exercise, 
-browser a page
-Close the sidebar by clicking the sidebar grippy
-F9 to turn off sidebar
-Select File | Print Preview
-Click "Close"
-Grippy appears (which is also non-responsive), despite sidebar being turned off


trunk - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a

Comment 8

[:Hb]

Confirm for 2.0.1pre rv:1.9.1.7pre

Comment 9

[Christopher Adams]

Attachment: same problem

Thanks from tioholemar1982.