Closed
Bug 147827
Opened 23 years ago
Closed 13 years ago
preferences window forgets position
Categories
(SeaMonkey :: Preferences, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: f.kater2, Unassigned)
Details
(Whiteboard: [2012 Fall Equinox])
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020528
BuildID: 2002052812
This little bug sounds uninteresting but concider the following:
I am using my taskbar at the top side of my screen. So the preferences menu
hides always a bit behind the taskbar. You can't even move it (with out moving
the whole taskbar to the bottom first).
Reproducible: Always
Steps to Reproduce:
1.open preferences
2.try to move it when your taskbar is on top of screen
3.
Actual Results: can't move because the window title bar of the preferences menu
disappears behind the taskbar
Expected Results: ..
This seems to be a general problem not only to mozilla. Also many ms-windwos
applications do not concider a taskbar on the top edge of the screen.
Comment 1•23 years ago
|
||
Well, my preferences box in 2002051006 on Win2k remembers its position.
If it does not with you, bug 145941 might depend on this one here (preferences
is at least movable).
Comment 2•23 years ago
|
||
Curious. User Agent: Linux i686, but you're talking ms-windows Taskbars.
Preference position saved for me W2k 2002052206
The taskbar is on top of everything, but that is normal windows operation.
Comment 3•23 years ago
|
||
reporter (Felix Kater): can you reproduce this bug with a recent build of
mozilla (for example, 1.1beta)? if so, please comment again with details. if
not, please resolve this bug as WORKSFORME. thanks.
Comment 4•23 years ago
|
||
Addition to my comment #1: even if Taskbar is on top of screen and the
resolution is set to 640x400, you have to drag the taskbar somewhere else and
move your preferences window to a position where its titlebar can be accessed
even with the taskbar on top of screen *only once*, because its position is
remembered.
This is common behaviour as you write yourself, Felix, and therefore not a bug
(INVALID).
If it really did not remember its position, it is WORKSFORME, but maybe you just
deleted the preferences file where the position is stored or lost your
preferences due to another bug (that would make it a DUPLICATE to complete the
list of possibilities...)?
| Reporter | ||
Comment 5•23 years ago
|
||
First, an addition to comment #2: Yes, I am using Mozilla both on W2k and Linux. :-)
Second: I checked the behaviour again on both systems, now with the newer
version 1.1a. As mentioned from other reporters on my W2k system mozilla stores
the position of the preferences window (now). Further, the first position (after
a reinstall) seems to be changed to the upper left corner of mozilla's main
window (and not the upper left corner of the screen). That's a good thing for
people haveing their task bar on top of the screen.
Third: This isn't a big issue but let me mention that on my linux system
(gentoo-linux, X, fvwm2) mozilla doesn't seem to store the position of the
preferences window. It is always placed near by the upper left corner of
mozillas main window.
Hope this help's.
As I am not used to change the status of a bug I hope you don't mind if I let
someone else decide what's the right status of this issue.
Thanks, Felix
Comment 6•23 years ago
|
||
I can reproduce this sing linux nightly 2002110804:
1) Select Edit->Preferences... to open the preferences window. It should open at
top left of the screen.
2) Move the preferences window somewhere else. Close it.
3) Select Edit->Preferences... again. It should open at top left of the screen
again.
Additionally: I'm using KDE, with a window placement policy for windows that
don't ask to be opened in a specified position. This placement policy isn't
being followed for the preferences window, which suggests mozilla is
specifically asking the window to be opened at the top left of the screen.
A few quick tests of bookmark manager, password manager, etc. suggest mozilla
isn't remembering window position for any of these.
Comment 7•23 years ago
|
||
Tested again using solaris nightly 2002120522. My desktop is gnome 2.
In this case preferences, bookmark manager, etc. are appearing in arbitrary
points on the screen. I believe gnome's window placement policy is determining
where they go. Again, this implies mozilla isn't giving the WM a strong hint
where to position windows.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•18 years ago
|
Assignee: bugs → prefs
QA Contact: bugzilla
Comment 8•17 years ago
|
||
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
It's a bit late to ask, but is this still reproducible in modern SeaMonkey and Linuxes versions?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INCO]
Comment 10•13 years ago
|
||
I just did a test on Linux, with a recent nightly build, running KDE 4.8.5 from (K)Ubuntu 12.04.1 LTS. Unlike on Windows, the position of the Preferences window was not remembered. However, this is expected. On Linux, some window managers take precedence in determining window positions, and KDE's KWin is one of them. The Preferences window placement is controlled by the sub windows settings which default to "economic" (examples of alternatives are "maximized" and "centered"). I couldn't find a global option to leave the placement to the application (which would allow SM to remember dialog positions), but the per-application override settings allow to do that (though I guess in that case it's KDE that will remember the placement, not SM).
In any case, it's not SM's fault that the WM takes precedence in window placement, so this is WFM from SM's perspective.
BTW, if you cannot grab the window title bar to move a window on Linux, try grabbing and dragging the window anywhere else while holding the Alt key. :-)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INCO] → [2012 Fall Equinox]
You need to log in
before you can comment on or make changes to this bug.
Description
•