Mike Schroepfer Reporter
	Description • 18 years ago

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060819 BonEcho/2.0b2

Please see the attached screenshot - on the 8-19 BonEcho build the "Tabs" panel on the prefs dialog has about half of the bottom section with whitepace.

	Phil Ringnalda (:philor)
	Comment 2 • 18 years ago

If you want to feel better about your Mac whitespace, try this: in a 0819 Windows build, close the prefs window with Security as the current pane, set the pref browser.preferences.animateFadeIn (the one that gives the Mac resizing pref panes) to true, reopen prefs, and switch to the Tabs pane. At least on my 1024x768 display, that stretches the window to the full height of the display, so it's just barely possible to get the Close button into view.

I'm guessing bug 349098.

	Phil Ringnalda (:philor)
	Comment 3 • 18 years ago

Even more "fun": with a Mac build, close prefs with the Tabs pane current, then reopen, Tabs won't have extra whitespace, but when you change to Content it will expand massively, and when you switch back to Tabs it will expand even more.

	Asaf Romano (gone) Assignee
	Comment 4 • 18 years ago

While working on this, I noticed how broken the animation code is (In particular, the contentHeight property together with the fact that pane._currentHeight is never set back to zero), I've a patch for that too here, but it has some issues. :-/

	Mike Connor [:mconnor]
	Comment 5 • 18 years ago

Comment on attachment 234646 [details] [diff] [review]
prefwindow-binding fix

r=me, this actually is important, especially for extensions that can't preprocess

	Phil Ringnalda (:philor)
	Comment 6 • 18 years ago

*** Bug 349434 has been marked as a duplicate of this bug. ***

	Asaf Romano (gone) Assignee
	Comment 7 • 18 years ago

Drivers: this is a pretty serious regression from bug 349098, switching between the prefpanes after the tabs pane is selected breaks the prefwindow as it can become higher than the entire available height. I've tested the patch with the three panes the patch might affect and they've not regressed.

Nominating for b2.

	Pardal Freudenthal (:ShareBird)
	Comment 8 • 18 years ago

(In reply to comment #7)
> Drivers: this is a pretty serious regression from bug 349098, switching between
> the prefpanes after the tabs pane is selected breaks the prefwindow as it can
> become higher than the entire available height. I've tested the patch with the
> three panes the patch might affect and they've not regressed.
> 
> Nominating for b2.
> 

Here is a screenshot on Windows showing how bad it can be.

https://bugzilla.mozilla.org/attachment.cgi?id=234699

Notice that the dialog buttons are not visible at all.

I've also tested the patch and it seems to work fine.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 9 • 18 years ago

Because it's possible to get the original window size back, we're not going to respin specifically for this bug. It will be release noted, though.

	dex_sf
	Comment 10 • 18 years ago

Is it possible that your patch caused a regression in the way the "Content" panel of the prefs is displayed on the Mac? 

	Phil Ringnalda (:philor)
	Comment 11 • 18 years ago

Since this is the not-checked-in-yet fix for that, "no".

	dex_sf
	Comment 12 • 18 years ago

Yup, sounds plausible. ;) Sorry!!

	Mike Schroepfer Reporter
	Comment 13 • 18 years ago

Comment on attachment 234646 [details] [diff] [review]
prefwindow-binding fix

a=schrep for drivers - approving all 181pending bugs now that tree is open.

	Mike Schroepfer Reporter
	Comment 14 • 18 years ago

Comment on attachment 234646 [details] [diff] [review]
prefwindow-binding fix

a=schrep for drivers - approving all [181approval pending] bugs now that tree is open.

	Asaf Romano (gone) Assignee
	Comment 15 • 18 years ago

1.8 branch: mozilla/toolkit/content/widgets/preferences.xml 1.31.2.23
trunk: mozilla/toolkit/content/widgets/preferences.xml 1.56

	Jo Hermans
	Comment 16 • 18 years ago

*** Bug 351286 has been marked as a duplicate of this bug. ***