mozilla ignores standard X command line options, like -geometry




Startup and Profile System
18 years ago
2 years ago


(Reporter: Mark Lehrer, Unassigned)


(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments, 5 obsolete attachments)



18 years ago
Netscape 4.x (and just about every version actually) respected -display,
-geometry, and so on. It would also save the screen size and next time
the user starts it, it uses the correct geometry.

However, mozilla complains when I specify geometry, and it always starts as
a teeny tiny window on my 1600x1200 screen.


Comment 1

18 years ago
Reassigning all of leger's unscreened Browser-General bugs to
for pre-screening and triage.


18 years ago
Assignee: nobody → neeti
Severity: minor → enhancement
Component: Browser-General → libPref
Summary: mozilla ignores standard X command line options, like -geometry → [4.xP] mozilla ignores standard X command line options, like -geometry

Comment 2

18 years ago
Marking as RFE, and (guessing here) assigning to libPref owner.


18 years ago
Assignee: neeti → don

Comment 3

18 years ago
This has nothing to do with prefs. This needs to go to the appshell team. Don ?


18 years ago
Assignee: don → mcafee
Severity: enhancement → normal
Component: libPref → XPApps
Priority: P3 → P2
Summary: [4.xP] mozilla ignores standard X command line options, like -geometry → mozilla ignores standard X command line options, like -geometry
Target Milestone: M15

Comment 4

18 years ago
Chris, can you handle this stuff?


18 years ago
Depends on: 23084

Comment 5

18 years ago
Related to, but not completely a dup of, bug 23084


18 years ago
Summary: mozilla ignores standard X command line options, like -geometry → [4.xP] mozilla ignores standard X command line options, like -geometry

Comment 6

18 years ago
spam: Restoring [4.xP], because this has worked in previous versions for years.

Comment 7

18 years ago
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
Bug #20196 is specifically about -display.


18 years ago
Depends on: 11185


18 years ago
Summary: [4.xP] mozilla ignores standard X command line options, like -geometry → mozilla ignores standard X command line options, like -geometry

Comment 9

18 years ago
Move to M16 for now ...
Target Milestone: M15 → M16

Comment 10

18 years ago
The -geometry command line option works in Netscape 3.X but it did not work

completely in the entire 4.X series.  I first reported this for -geometry in

4.0b2, and again in 4.0b7 and yet again in 4.0.  Specifically the size DOES work

but the POSITION does NOT in both Netscape 4.X and in Mozilla M14.  There is no

error message when a position is given on -geometry, but it is ignored and

manual window placement pops up anyway.


18 years ago
Keywords: nsbeta2
Target Milestone: M16 → M17

Comment 11

18 years ago
Putting on [nsbeta2-] radar. If you can find someone to help...let us know.
Whiteboard: [nsbeta2-]

Comment 12

18 years ago
Move to M20 target milestone.
Target Milestone: M17 → M20


18 years ago
QA Contact: nobody → BlakeR1234

Comment 13

18 years ago
*spam* changing qa contact from to me ( 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 14

18 years ago
->Cmd Line
Component: XP Apps → XP Apps: Cmd-line Features
QA Contact: BlakeR1234 → sairuh

Comment 15

18 years ago
nav triage team:
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3


17 years ago
Priority: P2 → P3
Blocks: 50201

Comment 17

17 years ago
has anyone tested this recently?
wow! using -height and -width now work --at least on linux [2000.10.30.09-n6].

what's the format for using -geometry? let me know and i'll test that.

Comment 19

17 years ago
The format is:   -geometry WxH+X+Y

where W is width, H is height, X is position from left (or from right if
negative), Y is position from top (or from bottom if negative).  Either size or
position may be omitted (the leading + or - indicates the size is omitted). 
When position is provided (and not overruled by the window manager) initial
window placement is non-interactive.
thanks to for describing -geometry syntax... unfortunately, while
-width and -height work, -geometry doesn't. ;(  i tried a couple of times:

./netscape -geometry 300x150
./netscape -geometry 1000x800+16+8

both attempts resulted in a browser window with the same dimensions as i had
previously used [ie, not 300x150 or 1000x800] --and positioning is ignored.
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: helpwanted, nsbeta1-

Comment 22

17 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
OK, there's good news and bad news. The good news is that I've tracked down
where we are going -width and -height:
(although I'm not sure which applies when.) Reading -geometry in this case to
get width and height values would not be too tricky.

The bad news is that, having followed the function calls about 10 levels in,
there seems to be no support for initial placement of windows - it seems that
somewhere deep in the window init code has complete discretion over where to put
it. So doing X and Y would be pretty tricky, and well out of my league.

So do we do width and height only from -geometry, or would that confuse people?



17 years ago
Keywords: nsbeta2, nsbeta3 → mozilla1.0
Whiteboard: [nsbeta2-][nsbeta3-]

Comment 24

17 years ago
Doing -width and -height only would not be the fix as I need initial placement
position as well. This is also broken in the entire Netscape 4.X series which
forces me to continue using Netscape 3.04, since I have a large and complex
virtual desktop setup consisting of nearly 100 windows, including 24 instances
of a web browser. Initial setup is done by a set of scripts, and placement
position is needed to get each window started into the correct virtual desktop.
It is not necessary that position be interfaced as -geometry, as I can code
scripts to use other options such as -xpos and -ypos, or set environment
variables. I just need some means to do initial position that does not affect
positioning windows brought up later during use.  This is what my original bug
report was all about.
In which case, this (probably - I'm not an expert) requires reasonably major 
internal surgery, and you are going to have to persuade someone more skilled 
than I to look into it. Or, at least, give me a pretty hefty clue. Sorry :-(

(/me wonders if window placement isn't a function of the window manager, and why 
it can't move it to wherever you want it.)


Comment 26

17 years ago
I am switching groups, and am turning this over to for a new
Assignee: mcafee → nobody

Comment 27

17 years ago
Adding my home email as a CC, since today is my last day at Corel.

Comment 28

16 years ago
*** Bug 96694 has been marked as a duplicate of this bug. ***

Comment 29

16 years ago
This appears to block tracking bug 33378.
Yes it does - thank you.

Blocks: 33378
*** Bug 113315 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
adding my email to cc list. 
taking bug
Assignee: nobody → cbiesinger
Keywords: helpwanted
Target Milestone: Future → mozilla1.0
Created attachment 69658 [details] [diff] [review]
patch, not working

ok... this patch should work, but doesn't
further investigation showed that this works fine if a window is already opened
(ie. mozilla is already started) but that it fails otherwise.

Comment 36

16 years ago
*** Bug 136444 has been marked as a duplicate of this bug. ***

Comment 37

16 years ago
You should call XParseGeometry instead of doing it yourself. It's more 
complicated than you think.
Created attachment 78563 [details] [diff] [review]
new patch, still not working

applies to current trunk & uses XParseGeometry (thus only works on X11
platforms, which is probably OK)

still doesn't work.
Attachment #69658 - Attachment is obsolete: true
Target Milestone: mozilla1.0 → Future

Comment 39

16 years ago
I have a workaround (based on Mozilla 1.0 release) that seems to
work-for-me (except it won't do coordinate 0,0).  I just posted
the code to list, and I'll try to attach
it to this bug report.

The context diff shows a block of code that appears to
be a fairly effective workaround to the problem of Mozilla not
supporting the -geometry option or the geometry resource in the
.Xdefaults file.  The diff is based on the 1.0 release and
appears to work in all experiments I have done.

A "good" solution would probably be to either use the -geometry
option and/or the geometry resource, or maybe to add a couple
of switches similar to -width and -height.  The environment
variable is just one simple way I could get information to this
code without having to modify any other files.

Comment 40

16 years ago
Created attachment 89593 [details]
context diff of a workaround for lack of -geometry support

Comment 41

16 years ago
I'm all for a a good kludge if it gets the job done but ...

If you want this to work on X then it should accept the usual X geometry 
semantics. You really should accept something like "800x600+-0+-0" which 
is clearly documented and readily available via a man page. You can 
position a window in the lower right corner without knowing the screen 
dimensions. It's also a lot shorter to type. Still, the latest patch is 
a good start.

Comment 42

16 years ago
Created attachment 89974 [details]
updated workaround block, no mention of licensing

Oops.  The lawyers seem to have become irked by the
license-related comments in the original workaround
block.	I apologize for having irked them.  This updated
code block is licensed in compliance with standard Mozilla
practice.  There, is that better?
Attachment #89593 - Attachment is obsolete: true
bugs w/o patches -> NEW
-> default owner, I don't really plan on working on this anymore
Assignee: cbiesinger → law
Priority: P3 → --
Target Milestone: Future → ---


15 years ago
Depends on: 187139

Comment 45

15 years ago
Created attachment 121181 [details] [diff] [review]
-u of attachment 89974 [details] + static +nspr
Attachment #89974 - Attachment is obsolete: true

Comment 46

15 years ago
Comment on attachment 121181 [details] [diff] [review]
-u of attachment 89974 [details] + static +nspr

oh yes, the // end block comment should die. CVS Blame/CVS Log will retain
credit for Robert if a variant of his work is committed.

how does this patch look?
Attachment #121181 - Flags: review?(akkana)

Comment 47

15 years ago
The patch does not fix the problem. It only allows a different,
non-standard, non-ICCCM-compliant way to solve a problem. Read this
bug's summary.
I would much rather see attachment 69658 [details] [diff] [review] made to work, instead of this hack
getting checked in. but then, it's not my decision... but keep in mind that that
attachment would not fix this bug as filed, see comment 0.

Comment 49

15 years ago
If I read the intent of attachment 69658 [details] [diff] [review] correctly, I would concur
that it is a better idea than my kludge.  However, at least for me
the need is to have -geometry govern the size and placement of _all_
document windows created, not just the first one created by browser
initialization.  If attachment 69658 [details] [diff] [review] does that, I'm all for it.
I don't think it does - did Netscape 4 do that?

Comment 51

15 years ago
Yes, with Netscape 4, -geometry governed the placement and size of
_all_ document windows the browser would create--at least that is
what I seemed to observe.

Comment 52

15 years ago
Actually, on Linux I see ns4 -geometry controlling the first window it opens; e.g.
    netscape -geometry 800x600 -news
opens the message center at 800x600. 

Comment 53

15 years ago
Okay, I'll correct myself.  I was using the following X
resources in my .Xdefaults file:

netscape*geometry: 980x1030+0+0
Netscape*geometry: 980x1030+0+0
Navigator*geometry: 980x1030+0+0

I would argue that Mozilla should honor the appropriate
X resources as well as it should honor the -geometry
switch.  (Obviously, the resource names should be
different for Mozilla than for Netscape.)
X Resources are entirely separate, please use another bug for them (possibly one
is filed already)

Comment 55

15 years ago
Netscape 4 uses -geometry for size, but not for placement.  X resources do work
for Netscape 4 and will size and place all windows.  Netscape 3 uses -geometry
for both size and placement but only for the first window.  I do not know if X
resources apply to all windows.

I would suggest that it is important that -geometry, or at least mechanism,
operate to size and place only the first window.  The reason for this is that
sometimes -geometry is used to place a window into an alternate desktop by means
of an offset greater than the screen size.  A session login initialization
script might pre-place the window there.  The problem is if that large offset
later applies to creation of additional windows while the initial window is
currently being viewed on the desktop, the additional window will be placed
elsewhere, possibly inaccessible, instead of in the current desktop.  This
behaviour is seen in Netscape 4 with X resources used to place windows.

See my comment of 2000-04-08.

Comment 56

14 years ago
Comment on attachment 121181 [details] [diff] [review]
-u of attachment 89974 [details] + static +nspr

Oh, I guess this was still pending.  I agree with those who said we should use
standard arguments, rather than a new and undiscoverable environment variable.
Attachment #121181 - Flags: review?(akkzilla) → review-

Comment 57

14 years ago
Mozilla 1.7 and firefox 0.8:
I have tried using -width -height and -geometry with mozilla browser and
firefox. These command line switches make no difference under X windows. This
bug blocks me from making a kiosk distribution based on moz or firefox, unless I
can cajole a window manager to do the job. 

-geometry is the standard way of defining the size of an application at launch
time with X windows.

All resources I have found so far talk about the -geometry command line
parameter which does not work with moz.

Comment 58

14 years ago
Any chance this will be fixed soon?  It's a big pain for -geometry/height/width
to not work, it forces me to start two separate Firefox processes (as me and as
another user): one for regular browsing at 800x900, and another for looking at
documentation which I have always maximized.
Why does this bug 20573 depend on 187139 ?

4+ years old, 27 votes.  

Any chance that a *nix user will ever be able to set the startup geometry of

Comment 60

13 years ago if you write a patch soon, it'll have a chance of being fixed
soon. how's the patch going?
Assignee: law → raul

Comment 61

13 years ago
With some guidance, I'd be willing to do it... anyone able to give a beginner
(to Mozilla development) some support?

Comment 62

13 years ago
(In reply to comment #61)
> With some guidance, I'd be willing to do it... anyone able to give a beginner
> (to Mozilla development) some support?

I'd probably start with "new patch, still not working" attached to this bug, and
try to find out why it doesn't work...


13 years ago
Attachment #78563 - Attachment is obsolete: true

Comment 64

13 years ago
Is this bug really blocking 50201?

It seems to me that the issue with this one is specific to X, where 50201 is
cross platform.  An example there shows that height and width can be recognized
but chrome functionality (menus, keyboard controls) is not there.

also look at bug #238607 (marked closed as a dup of #50201.)  It really looks
like it's close to being solved (size, at least, if not position.)  

Comment 65

12 years ago
Created attachment 190873 [details] [diff] [review]
"proof of concept" for setting window placement based on X resource

Okay, I have a "proof of concept" patch that at least sets X and Y position
(width and height not working for some reason that's beyond me) based on the X
resource "mozilla.geometry" (as set in a .Xdefaults file).  I have tested this
patch on Firefox 1.0.6 on Linux (MandrX LE2005).  This patch sets the position
(and should set size) of all windows (not just the first), which is what
Netscape 4.x did (but obviously with a different resource name).

Comment 66

12 years ago
"-geometry" is not working with firefox Tested today and very annoying. It ignores the windowmanagers also. Does firefox follow any X standards?

Comment 67

11 years ago
*** Bug 345602 has been marked as a duplicate of this bug. ***

Comment 68

11 years ago
Possibly won't fix per Bug 324137

Comment 69

11 years ago
Okay, Bug 324137 has been resolved as won't fix, but the comments there indicate that Mozilla should pressure gtk to have gtk_init handle the -geometry command-line option.  My wish is that Firefox would support the 'geometry' X resource that Netscape handled perfectly many years ago.  I even have a patch that I have inserted into source code for every Firefox release since I wrote it.  This bug report has 40 votes.  (It's going to get another if I hadn't already voted for it.)

Is there some course of action that can get the main Firefox codestream fixed so it will support either -geometry on the command line or (better) the X geometry resource that every other application that runs under X obeys?

For how many more years do users have to patch source code and compile because the main codestream is lacking basic functionality?

Comment 70

11 years ago
(In reply to comment #69)
> I even have a patch
> that I have inserted into source code for every Firefox release since I wrote
> it.

Do you care to share that patch with the rest of us?


Comment 71

11 years ago
Created attachment 251654 [details] [diff] [review]
unified diff of July 28, 2005 patch

The patch was posted as a attachment 190873 [details] [diff] [review] on July 28, 2005.  This is an updated version, same code, in unified diff format so it can be applied automatically.
Attachment #190873 - Attachment is obsolete: true

Comment 72

11 years ago
In case it might be of some use to someone else impacted by the lack of obedience to the geometry X resource, until or unless Firefox is able to be fixed, I have a short C program in works-for-me state in initial testing (haven't yet tried for hours-long stability) that attempts to work around this bug by checking for new browser windows every 40ms and moving any new ones to the proper position on the screen.  Its pretty rough, but it seems to show basic capability, if the user is willing to tweak macros to fit his/her desired geometry, etc.  If somebody wants it, I could attach it or email it.

Comment 73

9 years ago
This bug is almost nine years old and still not fixed in Firefox 3.0, and still bothering me. Should we plan a tenth anniversary party?

Comment 74

9 years ago
Wow.  I had no idea this bug was assigned to me.  I will definitely NOT be fixing this bug, I don't get to regularly use Linux as a desktop OS anymore.

I'd be up for a little anniversary party if it doesn't get fixed...  Yikes.
Assignee: raul → nobody
QA Contact: bugzilla → cmd-line

Comment 75

9 years ago
Things like -geometry should be handled transparently by the X toolkit. This was the case with X11 and Xt. For some reason unknown to me the GTK team decided not to implement -geometry in their toolkit and they still refuse to do so. This means that all GTK based apps lack support for -geometry.
I think Mozilla should communicate this with the GTK team. Mozilla is a big player in the market. You can influence the attitude of the GTK team.

Comment 76

9 years ago
Since it seems unlikely this will be fixed, I've filed a new bug #444319 to have the geometry options removed from the command line.

Comment 77

9 years ago
Weak. Very weak.

Comment 78

9 years ago
Agreed with comment #77.

I guess I'll need to file a new bug about the lack of obedience to the 'geometry' X resource.  The old Netscape browser obeyed it.  I submitted a proof-of-concept patch some time ago that does a pretty good job.

Comment 79

9 years ago
New bug #444496 filed for lack of obedience to geometry X resource.

Comment 80

9 years ago
My patch no longer compiles with Firefox 3.0.8, the first version 3 I had tried it on.  The problem is undefined references at link time.  All the right headers must be available, because the compile stage succeeds.  However, some library is apparently not available to the linker.  The three functions the linker can't find are XrmGetStringDatabase(), XrmGetResource(), and XrmDestroyDatabase().  There are several other Xrm*() functions that are apparently not a problem for the linker.

Any suggestions for getting the patch to work again?  Thanks.

Comment 81

9 years ago
I'm not convinced we want this, but moving to the correct component for now. Should -geometry affect only the main window, or also helper dialogs such as addons notifications, etc?
Severity: normal → trivial
Component: Cmd-line Features → Startup and Profile System
Product: Core → Toolkit
QA Contact: cmd-line → startup

Comment 82

9 years ago
Both -geometry on the command line and the geometry X resource worked with Netscape 4.x but have not worked for Mozilla or Firefox.  If I remember correctly, someone commented earlier in this report -geometry took effect only for the first window or the window opened as a result of that command.  The geometry X resource (as in xrdb, .Xresources, .Xdefaults) took effect for all document windows but not for helper dialogs.

Comment 83

9 years ago
(In reply to comment #81)

> Should -geometry affect only the main window, or also helper dialogs such as
> addons notifications, etc?

It should only affect the main window opened by invoking firefox with the -geometry option. (Same as other X applications.)

Comment 84

9 years ago
I'd argue against changing the Importance to "trivial" -- it frustrates a lot of users on Linux that there's no way to position the initial Firefox window, and it's very unusual among Linux apps in not allowing this (which probably explains the number of votes and comments this bug has gotten). I hear people voicing frustration about it pretty often, and trading not-quite-adequate attempts to work around it.

I'd be happy to help with getting Robert's patch working again, if there was a chance of getting it into the tree. bsmedberg, whose approval would we need and which branch whould it need to be applied to?

Comment 85

9 years ago
While I would appreciate some form of my patch, or something better, making it into the browser itself, my patch is (as was so well stated) "not-quite-adequate".  It does not take the -geometry command-line option.  It only takes the geometry X resource.  It could be extended to take input from the command-line option, but that would require more code.  Also, my patch appears to actually only set the location on the screen, not the width and height.  Firefox is pretty good about remembering the previous width and height, so that drawback hasn't bothered me.

Comment 86

9 years ago
I assume the "trivial" designation is due to the small number of votes. This bug is number 246 on the list of open bugs ordered by number of votes (the top bug has over 600 votes). It's near the top of my list but different people have different priorities.

Comment 87

9 years ago
OK, I take that back. The other three geometry bugs, which really should all be considered the same bug, have fewer votes than this one yet are "normal." If you combine all four bugs, you'd be at around number 120 on the list of bugs ordered by number of votes. Perhaps these should all be merged, and certainly the Importance of this bug should be changed to "normal."

Is there a way to combine all the geometry bugs, or make a metabug?

The others are #450852, #50201, and #444496 (yes, one has to do with X resources not command line options but I would argue these are all related).

Comment 88

9 years ago
Combining them would be fine with me, especially if it improves the chance for a fix.  Just to make sure the idea doesn't get lost, my emphasis, the reason I filed #444496, and the reason I have for years compiled Mozilla and now Firefox from source to insert my patch, I need a way to make _all_ main document windows open at the same size and location on the screen.  With Netscape 4.x, the X resource did that.  If there is a different way to accomplish the end goal of forcing size and location for all main document windows, I'm happy.  The reason I want this is I manually push a Firefox window to the right edge of the screen, then use middle click to open several links, each in its own window, and I need the new windows to all be at the same size and place.  I also have a script that opens several new browser windows in a sequence, and I need those windows to be at the same size and place.

Comment 89

9 years ago
I have filed a new bug #492194. While this bug and the related ones have to do with specific mechanisms, the new bug has to do with there being no way in general to set the geometry. If we can't have the geometry command line option or the X resource, maybe we can get something else.

Comment 90

8 years ago
As a dumb user, I want to be able to start up Pandora in an approprately sized window from the command line using 
  "firefox -a pandora -width 800 -height 500" 
but it will not size the window correctly for me.

I am not skilled enough to change the code, but perhaps I could change the man page to read "We're just kidding about these height and width options."

Comment 91

8 years ago
Reading bug #324137, which points to  , I just stumbled upon this: which obviously has an extra "=" and looks to me like possibly preventing vars width and height from being set (but I'm no expert and I don't know anything about Mozilla's source code).

BTW, when will this bug's importance be changed back to "normal"?

Comment 92

8 years ago
That's not a typo, and this bug is not of normal importance.

Comment 93

8 years ago
Mozilla developers don't care about X. In the headlong rush for market share, Microsoft products are the only ones that matter. This bug will never be fixed.

If you doubt that, take a look at bug #444440, which is a regression and an actual security risk, yet is marked "normal" and shows no signs of movement in the last year.

Comment 94

8 years ago
Relative to comment #92, you're right that this bug is not of normal importance.

To at least this user (me), this bug is _VERY_ _HIGH_ priority.  Because of this bug, I cannot use the standard Firefox binary builds and must compile every release from source after applying my source code patch.  I have been doing this for several years.  It has cost me an immense number of hours.  This bug alone would significantly motivate me to switch to a different browser if/when that became viable.

Comment 95

8 years ago
Robert, what's the status of your patch? And have you looked at comment 91 above, about the extra "="? If we had a working, acceptable patch the chances would be better for getting this fixed. I'm afraid the code is too gnarly for me. All the gtk init stuff is impenetrable.

Comment 96

8 years ago
You might take a look at the devilspie program. It helped me to work around the mozilla/firefox problem.

Comment 97

8 years ago
Johan, thanks for the tip about the devilspie program.  I bookmarked it for later study.

I looked at comment 91, but I had given the benefit of the doubt to the statement in comment 92 that the three equals signs in a row was not a typo.  It looks odd, but I see 2,116 occurrences of three equals signs in a row in the JavaScript code base of another project I'm helping as a volunteer.  It shouldn't be very difficult to test whether removing one of the equals signs fixes it.

My patch has been working pretty well for me until recently when a linking problem cropped up.  It might be a compiler or linker bug.  It might be a problem with the Mandriva 2009.0 library packaging.  I suppose it might be a problem somewhere in Firefox's makefiles.  IIRC, the linker couldn't find a few functions in the X resource database libraries.  I trimmed my patch for the time being to work around it.  My patch does cause a few side effects that may make it unsuitable for general consumption.  For example, JavaScript alerts come up as full sized.  Also, my patch fixes only the geometry X resource, not the command-line options.

Comment 98

8 years ago
Johan, thanks again for the tip about devilspie.  While it does not work with twm, it appears to work with fvwm2.

Comment 99

5 years ago
I use Mozilla products for the same reason I _occasionally_ use Microsoft and Autodesk products- the alternatives are just barely outside the feature and usability line I am willing to cross to escape Mozilla's non-existent niche-user support.

Someday I may re-draw that line unless design flaws like ignoring basic Unix-like window management conventions are removed and killed with fire.


5 years ago
Priority: -- → P5

Comment 100

4 years ago
Hello, just now I wrote a quick & dirty hack to address this on systems that support LD_PRELOAD (this includes Linux). Please note this is not a real solution, but a simple workaround. Enjoy.

Comment 101

4 years ago
Cool!  Another workaround, mentioned by Johan Vromans in comment #96, is a program called devilspie.  It has worked fairly well for me as well.  It detects new windows and moves them where they should be.  It's pretty configurable, and in some cases different geometries can be specified for different types of windows.

Comment 102

4 years ago
> Cool!  Another workaround, mentioned by Johan Vromans in comment #96, is a program called devilspie.  It has worked fairly well for me as well.  It detects new windows and moves them where they should be.  It's pretty configurable, and in some cases different geometries can be specified for different types of windows.

so, it's a program. that manages windows. I wonder where I've heard those words before...
You need to log in before you can comment on or make changes to this bug.