Closed
Bug 394881
Opened 18 years ago
Closed 18 years ago
[Mac] Prefpanes should specify heights.
Categories
(Firefox :: Settings UI, defect)
Tracking
()
VERIFIED
FIXED
Firefox 3 beta1
People
(Reporter: cbarrett, Assigned: sdwilsh)
References
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
4.38 KB,
patch
|
Details | Diff | Splinter Review |
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?
Comment 1•18 years ago
|
||
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.
Comment 2•18 years ago
|
||
So, the api regression of window.moveTo from gecko 1.8 is no longer on the 1.9 radar either, eh?
Comment 3•18 years ago
|
||
(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.
Updated•18 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Keywords: regression
Updated•18 years ago
|
Target Milestone: --- → Firefox 3 M9
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → comrade693+bmo
Flags: in-testsuite-
Flags: in-litmus?
Hardware: PC → All
Version: unspecified → Trunk
Assignee | ||
Comment 4•18 years ago
|
||
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 5•18 years ago
|
||
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.
Updated•18 years ago
|
Whiteboard: [has patch][need review mconnor]
Comment 7•18 years ago
|
||
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+
Updated•18 years ago
|
Whiteboard: [has patch][need review mconnor] → [has patch][has reviews]
![]() |
||
Comment 8•18 years ago
|
||
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.
Assignee | ||
Comment 10•18 years ago
|
||
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: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•18 years ago
|
Whiteboard: [has patch][has reviews]
Comment 11•18 years ago
|
||
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.
Description
•