Closed Bug 60200 Opened 24 years ago Closed 20 years ago

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

Categories

(SeaMonkey :: Sidebar, defect, P1)

x86
All

Tracking

(Not tracked)

VERIFIED WORKSFORME
Future

People

(Reporter: morbus, Assigned: bugs)

References

(Depends on 1 open bug, )

Details

(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
Status: UNCONFIRMED → NEW
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
Status: NEW → ASSIGNED
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 http://bugzilla.mozilla.org/show_bug.cgi?id=82041 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 close...got 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
Status: ASSIGNED → NEW
-> 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-
retargeting
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
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.