If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

SeaMonkey
Sidebar
15 years ago
8 years ago

People

(Reporter: tracy, Unassigned)

Tracking

(Blocks: 1 bug)

Bug Flags:
blocking1.4b -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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.

Updated

15 years ago
Flags: blocking1.4b?
Keywords: nsbeta1

Comment 1

15 years ago
Updating qa contact to gbush@netscape.com
QA Contact: sujay → gbush
navtriage: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 3

15 years ago
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).

Updated

15 years ago
Flags: blocking1.4b? → blocking1.4b-

Comment 4

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

Behavior appears to persist since versions from 2003.
Product: Browser → Seamonkey
related to bug 215643?

Comment 6

12 years ago
(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.
(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
Assignee: samir_bugzilla → sidebar
QA Contact: agracebush
Blocks: 215643

Comment 8

8 years ago
Confirm for 2.0.1pre rv:1.9.1.7pre
You need to log in before you can comment on or make changes to this bug.