294360 - Preferences GUI, wrong size and not supporting xinerama

Status: RESOLVED DUPLICATE of bug 410337

(Firefox :: Settings UI, defect)

Description

[kick rocks]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050516 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050516 Firefox/1.0+

The new preference gui is too small.  The buttons are cut and not readable. 
Resizing this screen does allow them to be displayed until gui is re-invoked. 
The gui has no support for xinerama.  Either appears in center of entire desktop
or center of primary display.  Most applications remember the last place it was,
or center on the window that requested the preference gui. 

Reproducible: Always

Steps to Reproduce:
1. Start preference gui
2. move to second monitor and close
3. restart  gui

Actual Results:  
The gui starts again on primary display. and has to be re-sized again

Expected Results:  
The gui should have been tested so it's size would not be a problem.  Or
dynamically size itself, and appear in the last location not centered on desktop
every time.

This was built with --enable-xinerma on and off.

Comment 1

[Nickolay_Ponomarev]

See bug 283697 for cropped panels. The rest of your report is unclear. What is
xinerama?

Comment 2

[kick rocks]

(In reply to comment #1)
> See bug 283697 for cropped panels. The rest of your report is unclear. What is
> xinerama?

Multihead Displays.  On multihead systems, the preference gui appears centered
on the primary display.  Window requesting preference gui may have been third or
fourth.  Application should be aware of multiple screens/displays
--enable-xinerama option exists in build, but doesn't effect outcome.

Comment 3

[olecom]

Maybe this will be offtopic, sorry.

Is it possible to have configure or platform specific option to restore
old pref. dialog window ?


On my linux-gnu box it's very ugly and i (maybe everyone who just works)
want to have good intefrace with long usage time.
Plus.
+ there was much critiсism for tab in tabs for AOL 8.0, now we have it in
pref->advanced(this is tab)->[tabs:]general,update,security;
+ firefox on gtk2 uses gconf's themes, but no installed or something, and
it is good for me: i can setup my xfce environment to be consistent; new
and old dialogs doesn't use icons from standard themes for [close],[cancel], etc.
+ may be continued;

As for xinerama, i think that wm should do all the work, applications just
needed to not to force window management.

Comment 4

[Steven Walter]

(In reply to comment #3)
> As for xinerama, i think that wm should do all the work, applications just
> needed to not to force window management.

This problem didn't occur in Firefox 1.0.6, this is a regression and should be
fixed.  The problem is that Firefox is getting exactly what it's asking (to be
put in the middle of the screen), when that isn't really what is wants.  Being
ignorant of WM specifics as I am, I don't know what the solution is, maybe to
request placement in the middle of the current workspace or something.  Most
applications seem to not have this problem, however.

Comment 5

[Sean d'Epagnier]

I have found with firefox 1.0.7 1.5 and 1.6a, when the preferences dialog is opened (for a plugin or the main preferences), it is centered across all screens, so half is on one monitor, half on the other.

I propose two solutions (both can be used)

1. It should be centered in the current monitor that the window of firefox that opened it is in.

2. Preferences dialogs save their position, so it may be inconveniently located once, but after moved it will always go back to where it was.

I realize this isn't an easy problem to fix, but it does not occur in mozilla!

Thank you

Comment 6

[Haakon Riiser]

This bug is still present in 2.0.0.1:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1

It also affects extensions' preference dialogs.

Comment 8

[Sylvain Pasche]

I opened a bug for the more general issue which is the cause of this one. That also affects Mac apparently (and maybe Windows). I'm setting this one as a duplicate, because solving the other will solve this one too.