20573 - Firefox ignores standard X command line options, like -geometry

Status: NEW

(Toolkit :: Startup and Profile System, defect, P5)

Description

[Mark Lehrer]

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.

Thanks!
Mark

Comment 1

[Eli Goldberg]

Reassigning all of leger's unscreened Browser-General bugs to [e-mail]
for pre-screening and triage.

Comment 2

[Matthew T (active 1999-2002)]

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

Comment 3

[Suresh Duddi (gone)]

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

Comment 4

[don]

Chris, can you handle this stuff?

Comment 5

[Chris McAfee]

Related to, but not completely a dup of, bug 23084

Comment 6

[Matthew T (active 1999-2002)]

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

Comment 7

[leger]

Setting the keyword all open [4.xp] bugs to 4xp.

Comment 8

[Matthew Tuck [:CodeMachine]]

Bug #20196 is specifically about -display.

Comment 9

[don]

Move to M16 for now ...

Comment 10

[Phil Howard]

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.

Comment 11

[leger]

Putting on [nsbeta2-] radar. If you can find someone to help...let us know.

Comment 12

[don]

Move to M20 target milestone.

Comment 13

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
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 
[e-mail])

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

Comment 14

[Blake Ross]

->Cmd Line

Comment 15

[johng]

nav triage team:
[nsbeta3-]

Comment 16

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 17

[Jon Granrose]

has anyone tested this recently?

Comment 18

[sairuh (rarely reading bugmail)]

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

[Phil Howard]

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.

Comment 20

[sairuh (rarely reading bugmail)]

thanks to [e-mail] 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.

Comment 21

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is not a Netscape beta stopper.

Comment 22

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 23

[Gervase Markham [:gerv]]

OK, there's good news and bad news. The good news is that I've tracked down
where we are going -width and -height:
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#512
and
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#690
(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?

Gerv

Comment 24

[Phil Howard]

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.

Comment 25

[Gervase Markham [:gerv]]

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.)

Gerv

Comment 26

[Chris McAfee]

I am switching groups, and am turning this over to [e-mail] for a new
owner.

Comment 27

[John Griggs]

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

Comment 28

[timeless]

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

Comment 29

[Damian Yerrick]

This appears to block tracking bug 33378.

Comment 30

[Gervase Markham [:gerv]]

Yes it does - thank you.

Gerv

Comment 31

[Matthias Versen [:Matti]]

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

Comment 32

[tan]

adding my email to cc list. 

Comment 33

[Christian :Biesinger (don't email me, ping me on IRC)]

taking bug

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch, not working

ok... this patch should work, but doesn't

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[R.K.Aa.]

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

Comment 37

[tenthumbs]

You should call XParseGeometry instead of doing it yourself. It's more 
complicated than you think.

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: 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.

Comment 39

[Robert Riches]

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 [e-mail], 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

[Robert Riches]

Attachment: context diff of a workaround for lack of -geometry support

Comment 41

[tenthumbs]

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

[Robert Riches]

Attachment: 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?

Comment 43

[Christian :Biesinger (don't email me, ping me on IRC)]

bugs w/o patches -> NEW

Comment 44

[Christian :Biesinger (don't email me, ping me on IRC)]

-> default owner, I don't really plan on working on this anymore

Comment 45

[timeless]

Attachment: -u of attachment 89974 + static +nspr

Comment 46

[timeless]

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?

Comment 47

[tenthumbs]

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.

Comment 48

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[Robert Riches]

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.

Comment 50

[Christian :Biesinger (don't email me, ping me on IRC)]

I don't think it does - did Netscape 4 do that?

Comment 51

[Robert Riches]

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

[tenthumbs]

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

[Robert Riches]

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.)

Comment 54

[Christian :Biesinger (don't email me, ping me on IRC)]

X Resources are entirely separate, please use another bug for them (possibly one
is filed already)

Comment 55

[Phil Howard]

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

[Akkana Peck]

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.

Comment 57

[Nick Hill]

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

[Raul Acevedo]

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.

Comment 59

[NoLongerUsingFirefoxDueTo299372]

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
mozilla?

Comment 60

[timeless]

[e-mail]: if you write a patch soon, it'll have a chance of being fixed
soon. how's the patch going?

Comment 61

[Raul Acevedo]

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

Comment 62

[Pascal S. de Kloe]

http://www.mozilla.org/hacking/coding-introduction.html

Comment 63

[Christian :Biesinger (don't email me, ping me on IRC)]

(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...

Comment 64

[Aaron Evans]

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

[Robert Riches]

Attachment: "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

[Michael]

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

Comment 67

[Kevin Brosnan]

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

Comment 68

[Kevin Brosnan]

Possibly won't fix per Bug 324137

Comment 69

[Robert Riches]

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

[Adam Sjøgren]

(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?

Thanks!

Comment 71

[Robert Riches]

Attachment: 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.

Comment 72

[Robert Riches]

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

[Jim Rees]

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

[Raul Acevedo]

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.

Comment 75

[Johan Vromans]

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

[Jim Rees]

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

[Johan Vromans]

Weak. Very weak.

Comment 78

[Robert Riches]

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

[Robert Riches]

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

Comment 80

[Robert Riches]

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

[Benjamin Smedberg]

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?

Comment 82

[Robert Riches]

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

[Adam Sjøgren]

(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

[Akkana Peck]

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

[Robert Riches]

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

[Jim Rees]

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

[Jim Rees]

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

[Robert Riches]

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

[Jim Rees]

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

[C. Conrad Cady]

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 http://pandora.com" 
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

[LL]

Reading bug #324137, which points to http://mxr.mozilla.org/mozilla/source/browser/components/nsBrowserContentHandler.js#536  , I just stumbled upon this: http://mxr.mozilla.org/mozilla/source/browser/components/nsBrowserContentHandler.js#629 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

[Benjamin Smedberg]

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

Comment 93

[Jim Rees]

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

[Robert Riches]

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

[Jim Rees]

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

[Johan Vromans]

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

Comment 97

[Robert Riches]

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

[Robert Riches]

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

Comment 99

[Quinn]

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.

Comment 100

[Milan Pikula]

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.

http://www.ipsec.info/w/t/override-gtk-geometry.c

Comment 101

[Robert Riches]

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

[Alex Xu]

> 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...

Comment 103

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 4 duplicates and 49 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 104

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.