349343 - Tabs pane of preferences has mucho whitespace on Mac

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P1)

Description

[Mike Schroepfer]

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.

Comment 1

[Mike Schroepfer]

Attachment: Screen cap of tabs pane of prefs dialog

Comment 2

[Phil Ringnalda (:philor)]

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.

Comment 3

[Phil Ringnalda (:philor)]

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.

Comment 4

[Asaf Romano (gone)]

Attachment: prefwindow-binding fix

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. :-/

Comment 5

[Mike Connor [:mconnor]]

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

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

Comment 6

[Phil Ringnalda (:philor)]

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

Comment 7

[Asaf Romano (gone)]

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.

Comment 8

[Pardal Freudenthal (:ShareBird)]

(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.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 10

[dex_sf]

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

Comment 11

[Phil Ringnalda (:philor)]

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

Comment 12

[dex_sf]

Yup, sounds plausible. ;) Sorry!!

Comment 13

[Mike Schroepfer]

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

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

Comment 14

[Mike Schroepfer]

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

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

Comment 15

[Asaf Romano (gone)]

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

Comment 16

[Jo Hermans]

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