From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2) Gecko/20010708 BuildID: 2001070803 The Image manager windows content doesn't resize with the window, the button and internal "frame" should fallow... Reproducible: Always Steps to Reproduce: 1. Reduce the vertical size of the image manager window. 2. 3. Actual Results: Buttons are inaccessible AFTER resize... Expected Results: Buttons should be accessible AFTER resize...
win98, mozilla 2001070604: The content does resize correctly, but the minimum vertical size of the list area is rather high, causing the problem as described.
->image mgr folx
Assignee: pchen → morse
QA Contact: sairuh → tpreston
Same is true for cookie manager (not surprising since they share the same xul file). But the password manager is working fine. That's a separate xul file but the two xul's were derived from each other. So it should be a simple thing to look at the password manager xul to see what it is doing differently.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0
Seems the height of the hidden "cookiesTab" is interfering?
The same is not true for the Password Manager dialog. Perhaps some magic can be borrowed from that dialog...?
Isn't that what I said?
Component: XP Apps → Cookies
Summary: Image Manager: Bad vertical resizing → Cookie and Image Manager: Bad vertical resizing
Priority: -- → P4
Target Milestone: mozilla1.1alpha → mozilla1.2beta
Seems related to bug 158761
reassigning to hewitt since he has bug 128496
Assignee: morse → hewitt
Status: ASSIGNED → NEW
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] On my test, bottom buttons stay visibles as "long" as they can, but the list display becomes "messy" asa the list height becomes less than 2 lines.
*** Bug 213470 has been marked as a duplicate of this bug. ***
if someone implements a way of enforcing minimum dialog sizes, we can implement those. But at this point, this is probably as good as its going to get. dwitte, mvl, we could fix this for image manager if we broke cookie and image manager into separate files, otherwise this is effectively WONTFIX (or more accurately CANTFIX)
Assignee: hewitt → mconnor
QA Contact: tpreston → cookieqa
maybe we can fix it for the image manager by not hiding the unused (cookie related) tabs, but delete them. I mean, the dom nodes. Or setting display=none instead of hidden=true.
Created attachment 145423 [details] [diff] [review] proposed fix for image manager (checked in) By hiding the actual tabpanel resizing works. Actually, by hiding the contents of the tabpanel. Hiding the panel itself will cause weirdness.
Comment on attachment 145423 [details] [diff] [review] proposed fix for image manager (checked in) fun with tabpanels! I don't like the dummySystem name though, maybe something like cookiePanel would be better? r=me with that nit
Attachment #145423 - Flags: review?(mconnor) → review+
It isn't the actual panel. From the xul perspective, the whole added vbox doesn't make sense. So it is actually a dummy. The only reason it is there is to hide it.
dummyBox? dummyContainer? I think its really the system part that doesn't make sense to me
well, ok. dummyContainer it is.
Comment on attachment 145423 [details] [diff] [review] proposed fix for image manager (checked in) rs=darin
Attachment #145423 - Flags: superreview?(darin) → superreview+
Comment on attachment 145423 [details] [diff] [review] proposed fix for image manager (checked in) Patch was checked in. Leaving bug open for the cookie manager part.
Attachment #145423 - Attachment description: proposed fix for image manager → proposed fix for image manager (checked in)
Tabpanels are really a sort of deck, and I'm guessing that the deck frame twiddles the frames of its children. Now those children with hidden="true" don't have frames, thus confusing the deck frame into omitting them from its sums. Setting collapsed="true" on the panel would have worked in this case. (Note that it's still better to use hidden="true" on the tab.)
-> default owner
Assignee: darin → nobody
Target Milestone: mozilla1.2beta → ---
13 years ago
Priority: P4 → --
wfm in firefox 1.5, closing out as wfm.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.