Closed Bug 394881 Opened 13 years ago Closed 12 years ago

[Mac] Prefpanes should specify heights.

Categories

(Firefox :: Preferences, defect)

All
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3 beta1

People

(Reporter: cbarrett, Assigned: sdwilsh)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

bug 393117 was only the first part of fixing the prefs window on mac. Part 2 is to give the window absolute heights, so it can have the same behavior windows has, i.e. not resize at all, and be big enough for the tallest prefpane.

Eventually we'd like to get the resizing behavior fixed, but on the widget end we've already sunk too much time on it, and there are more important things to do.
Flags: blocking-firefox3?
Damon, this needs to block, since the API that would have fixed this bug was backed out. It's a regression and it's basically awful looking.
So, the api regression of window.moveTo from gecko 1.8 is no longer on the 1.9 radar either, eh?
(In reply to comment #1)
> Damon, this needs to block, since the API that would have fixed this bug was
> backed out. It's a regression and it's basically awful looking.

Nevermind this comment, the resizing bug is the regression, not this one.
Flags: blocking-firefox3? → blocking-firefox3+
Keywords: regression
Target Milestone: --- → Firefox 3 M9
Assignee: nobody → comrade693+bmo
Flags: in-testsuite-
Flags: in-litmus?
Hardware: PC → All
Version: unspecified → Trunk
Attached patch v1.0 (obsolete) — Splinter Review
So, this makes things much better on my end.  Occasionally I can get it to do some strange things when going to/from the Applications tab, but I can't find steps to reproduce it consistently.  We could ifdef out the code that calls window.sizeToContent in the binding for the prefwindow when we change our selected pane, but I'm not even sure if that'd help (it's unclear what was causing the height to change).

I'm also not sure if I need to change the entity name since I changed the value of the string.  I know for strings that is usually the case, but since this is a sizing thing, I'm not sure if that same rule applies.
Attachment #284807 - Flags: review?(gavin.sharp)
Comment on attachment 284807 [details] [diff] [review]
v1.0

mconnor should review this... Disabling animateFadeIn entirely sounds like a bad idea to me. Bug 355177 is marked blocking1.9+ - is it not going to get fixed?
Attachment #284807 - Flags: review?(gavin.sharp) → review?(mconnor)
It is unlikely that we're going to get animating working. Please work towards getting the preferences working correctly without animation and we can add animation and turn it on if we can later.

IOW, don't wait around for animation to get the pref panes shippable.
Whiteboard: [has patch][need review mconnor]
Comment on attachment 284807 [details] [diff] [review]
v1.0

r=me, this isn't perfect by any means, but its better than the current situation.  We can switch back to animation when that actually works right on Mac.
Attachment #284807 - Flags: review?(mconnor) → review+
Whiteboard: [has patch][need review mconnor] → [has patch][has reviews]
Comment on attachment 284807 [details] [diff] [review]
v1.0

>Index: browser/locales/en-US/chrome/browser/preferences/preferences.dtd
>===================================================================
>RCS file: /cvsroot/mozilla/browser/locales/en-US/chrome/browser/preferences/preferences.dtd,v
>retrieving revision 1.10
>diff -u -8 -p -r1.10 preferences.dtd
>--- browser/locales/en-US/chrome/browser/preferences/preferences.dtd	6 Sep 2007 04:55:48 -0000	1.10
>+++ browser/locales/en-US/chrome/browser/preferences/preferences.dtd	14 Oct 2007 06:05:09 -0000
>@@ -1,15 +1,15 @@
> 
> <!ENTITY  prefWindow.titleWin     "Options">
> <!ENTITY  prefWindow.titleGNOME   "&brandShortName; Preferences">
> <!-- When making changes to prefWindow.styleWin test both Windows Classic and
>      Luna since widget heights are different based on the OS theme -->
> <!ENTITY  prefWin.styleWin        "width: 42em; min-height: 44em;">
>-<!ENTITY  prefWindow.styleMac     "width: 47em;">
>+<!ENTITY  prefWindow.styleMac     "width: 47em; min-height: 45em;">
Please change the entity name here and in the corresponding xul file so localizers will pick this up.
Attached patch v1.1Splinter Review
for checkin
Attachment #284807 - Attachment is obsolete: true
Checking in browser/components/preferences/preferences.xul;
new revision: 1.15; previous revision: 1.14
Checking in browser/locales/en-US/chrome/browser/preferences/preferences.dtd;
new revision: 1.11; previous revision: 1.10
Checking in browser/app/profile/firefox.js;
new revision: 1.213; previous revision: 1.212
Checking in toolkit/content/widgets/preferences.xml;
new revision: 1.69; previous revision: 1.68
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews]
Blocks: 386358
Litmus Triage team: marcia will handle testcase.
Verified FIXED: the Mac "jumping pref panel" bug is long gone:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.