Open Bug 72330 Opened 24 years ago Updated 18 years ago

don't let the windowmanager position windows under X (pref?)

Categories

(SeaMonkey :: UI Design, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: jhayryne, Assigned: jag+mozilla)

Details

build 2001031408

it currently feels like mozilla is not giving any hints to window manager about
positioning of new navigator windows under X.

on enlightenment, there are not many options about window placement, and the
default behaviour is to try to be economic and find least occupied part of the
screen for new windows. however, enlightenment does NOT force these positions
and many programs like xmms, gkrellm save their previous locations themselves
and open at the same place on next startup. i think this is the way most window
managers do it and is also considered the right behaviour.

i think mozilla should try to be smart and handle it's own window positioning,
and CASCADE new navigator windows so that they overlap each other with title
bars visible. this is very important with a web browser which often has many
windows open and window managers usually don't do cascading or can't do it the
right way.

most, if not all window managers can be configured to respect programs hints
about positioning which is also the right thing to do, so this way we would get
consistent behaviour with mozilla windows regardless of what window manager
we're using under X.

other bugs i found about new window placement were either windows or mac only
and marked fixed (bug 25455), or said that we shouldn't do window positioning at
all under X and have wm's do it (buf 49802). i disagree. since a web browser
often has many windows open, window managers just can't do placement the right way.

a pref for turning window manager hints on/off would be nice for people that
don't want this, but i feel it's very important that cascading on x window
systems is implemented, it's definitely not only windows users that want that.
hmm, buf 49802 == bug 49802

also see (bug 35569). it discusses dialog window placement under X which i think
is somewhat related -- the general (un)usage of windowmanager hints.

i'll also cc pavlov since i figured he knows something about these issues.
If this change is made to Mozilla, there absolutely has to be a pref to turn it
off.  I do not want Mozilla to do its own cascading.  I have my WM set up the
way I want, and I do not want Mozilla messing with that.  Also, I very much
dislike the cascading on Windows, and I wish there was some way to turn it off
there.
setting status to new, severity to enhancement, ccing some UI people and some
Unix people.  For what it's worth, I agree with Stephen.  Since this bug and bug
49802 are in direct contradiction, this feature should not be implemented
without a way to override it.

In fact, I would say that the best thing to do would be to make this a pref that
is on by default on Win/Mac and off by default on Unix.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: new window placement under linux / x window system → don't let the windowmanager position windows under X (pref?)
 Mozilla should not default to thinking that it is smarter than the user's
window manager about placing windows. The user has their window manager set
to the placement policy they like, and it is pure arrogance on Mozilla's
part to think it can do better than that.
->bryner
Assignee: pchen → bryner
Sure, we could pref this, although I don't think many people would bother to
change it...

-> 0.9.9
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
I would recommend not doing this at all.  With the advent of tabbed browsing, I
believe this whole issue has become moot.  And if it is done, I certainly want a
way to turn it off since I do not wany any program highjacking control of window
placement away from my window manager.  I mean, the whole point of picking the
odd ball window manager that I use is because I like the way it works, including
window placement.
What does tabbed browsing have to do with this? nothing?

I'd like this pref, even if hidden one, because I believe that one should be
able to get windows-like behavior on linux (and vice-versa). F everything GUI,
not just this bug.
Marko, should you not just get a windowmanager with Windows-like behavior?  That
seems like a far more reasonable solution to me....  
Target Milestone: mozilla0.9.9 → Future
Product: Core → Mozilla Application Suite
This bug of not restoring the main-window location upon startup is still
affecting my version of Mozilla [Mozilla/5.0 (X11; U; SunOS sun4u; en-US;
rv:1.7.8) Gecko/20050512].  I'm running this under CDE on Solaris 10.

This is really frustrating.  I can see that both the window size and
window location are being saved in localstore.rdf when the browser exits,
but only the window size is being effectively restored upon startup.

The issue is not moot just because we have tabbed browsing nowadays.
I want the initial browser window in a particular location on my screen,
and that has nothing to do with whatever happens afterward.

Depending on the WM for window placement doesn't make much sense.  Previous
commentators seem to think that the WM will somehow select a placement which
will tile the screen nicely.  But typically, I stack most of my terminal
and browser windows, and just rotate the stack to flip between them.  That
gives me the greatest screen area to work with in every application.  Having
the initial window wander around means the stacking order gets intermixed
with that of various icons I've got stashed on the screen, which makes for
excessive stack-rotation operations and a bit of operator confusion.

Since this bug has been outstanding for so long and it doesn't look like
a fix is in sight any time soon, I've come up with the following workaround.
It works for my situation but may need adjustment for yours.

I've set the browser to display the Home Page upon startup, and set the
Home Page Location to this string:

javascript:window.location="http://www.google.com";self.setTimeout("self.moveTo(0,0)",1)

This works at startup.  It also has the (benign, for my situation) side
effect of re-aligning the window every time I press the browser's Home
button.  It is somehow not enough to skip the extra layer of encapsulation
within the timeout.  In such a formulation, the alignment occurs when you
press the Home button, but for some reason it still does not take effect
at startup.

I hope this bug gets fixed for real sometime soon.  The workaround above
is practical but aesthetically ugly and hard to discover.
Cute idea! Unfortunately it's still windowmanager dependant. At least, it
doesn't work for me with a CVS firefox under fvwm, though the url works fine if
I load it in a browser after startup. So it's not a workaround for everyone,
alas. Increasing the timeout doesn't help.
Assignee: bryner → jag
Status: ASSIGNED → NEW
QA Contact: bugzilla
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.