Closed Bug 60200 Opened 20 years ago Closed 16 years ago

Sidebar->Tabs -> Customize Window gets larger each open.


(SeaMonkey :: Sidebar, defect, P1)



(Not tracked)



(Reporter: morbus, Assigned: bugs)


(Depends on 1 open bug, )


(Whiteboard: investigating, no eta)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
BuildID:    20001114404

When "Customizing My Sidebar", the window for customization gets larger in 
height only each time the window is open, eventually becoming so large that 
buttons and window title are shown off screen. The size is remembered across 
multiple closes and opens. 

The window remains resizable, however, resizing back down to "normal" size is 
only a temporary fix. The height only enlarging starts anew.

Reproducible: Always
Steps to Reproduce:
1. Open browser.
2. Expand sidebar.
3. Click "Tabs" -> "Customize My Sidebar"
4{a|b}. Perform nothing|something.
5. Say "Ok"
6. Repeat.

Actual Results:  As explained in the description.

Expected Results:  Mozilla should not expand the height of the sidebar to 
compensate for lots of sidebar entries.

This may have happened because of my overzealousness for the feature. I had 
gone to DMOZ and started added willy nilly tons and tons of sidebar items. 
After I had my fill, I tried to "break it for the sake of all that is good" and 
continued to add sidebars until the new title tabs were no longer seen in the 
sidebar (although they were seen and choosable in the Tabs -> Customize window).

I noticed the behaviour described in the Description after having gone in to 
remove the additional sidebars.
confirmed on win98 build id 2000111508. The 'customize my sidebar' pref panel
sems to be growing in height each time it is opened until it reaches the full
height of my screen.
yuckk....I see this, the dialog inflates like a baloon.. ;). Severity:major
Severity: minor → major
Ever confirmed: true
using build 2001012612 mtrunk win32 installer.

this is still an ongoing, signficant problem.  after 5-6 openings of the
customize sidebar dialog, it exceeds a 800x600 sized screen.  increases in size
are remembered with program restart.

suggest keywords correctness and helpwanted.

spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay
Marking catfood.

This really happens and when the window height is large, there is no way to hit
[ok] button anymore!!
Keywords: nsCatFood
sujay - can you confirm if this still happens? 
Keywords: nsCatFoodnsCatFood+
Target Milestone: --- → mozilla0.9.2
I definitely see this happening on latest builds.(5/1)

good catch.
I would consider this a stopper. No real workaround exists anymore, even
resizing the window, due to the fact that the button positions don't resize
relative to the window.
Keywords: nsbeta1+
sidebar triage: there is no good workaround for this problem, hence upgrading to
a P1. 
Priority: P3 → P1
First glance:Window size is kept in RDF and there is a JS call.  Something is
going wrong there and needs a looksy.   The js debugger will we great for this bug.
Risk:not much
length:2 days
reason:Big windows are no fun
Whiteboard: 2 days
Whiteboard: 2 days → 2 days, eta 6/8
sidebar+pdt triage: yes this is an rtm stopper. 
Open window
close window
X = 754 
Y = 119
H = 778
W = 578

Reopen window
X = 506 
Y = 95
H = 805
W = 587

In the RDF localstore.rdf the window dimensions are getting
saved correctly.  The problem is when the window is being reopened
the values are incorrect.
kicking out to next week due to
fire drill and fix
Whiteboard: 2 days, eta 6/8 → 2 days, eta 6/15
Whiteboard: 2 days, eta 6/15 → 2 days, need new eta
Given that the status of this is that
 - we do not have a fix
 - there is a workaround, i.e. can manuallyt resize the window
 - this is not a very common operation

Can we move this beyond mozilla0.9.3 (i.e. out for N6.1?)
This would help a lot and free us up to work on other more egregious bugs. 
moving to 0.9.3 since i think i'm sidetracked by other bugs of more 
important value.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Lets be sure to get this in the first limbo build. If you get your list to zero, 
lets put this back on m0.9.2. radar. 
Keywords: nsBranch
Whiteboard: 2 days, need new eta → 2 days, 6/10
matt - where are you on this one? Ben - can you help? 
Whiteboard: 2 days, 6/10 → 2 days, 7/10
Assignee: matt → morse
-> morse
*** Bug 90021 has been marked as a duplicate of this bug. ***
Whiteboard: 2 days, 7/10
reassigning to ben to take a look see
Assignee: morse → ben
Whiteboard: investigating, no eta
Not a stopper, removing nsBranch per vishy, setting dependency.
Depends on: 90276
Keywords: nsBranch
moving to mozilla0.9.4.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 94973 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.4 → mozilla1.1
nav triage team:

Since this is dependent on bug 90276 and how often do you customize sidebars
anyway, pusing out to mozilla1.1.
Confirming bug on OS/2 build 2002102512
OS -> All
OS: Windows 98 → All
A fix has been checked in for bug 193606, which was for a similar problem with
the cookie window. Perhaps a similar solution would work here?
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b-
Target Milestone: mozilla1.1alpha → Future
priority should grow over time...
I've observed this one today in 1.5 trying to add my old bookmarks back into the
sidebar... and found it's three years old.
I observed this one today in 1.5... ...and found it's three years old.
Wouldn't bugs increase their priority over time ?
this works for me with mozilla trunk build 2004-11-10-06-trunk on windows
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.