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

Reassigning all of leger's unscreened Browser-General bugs to nobody@mozilla.org for pre-screening and triage.

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

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

Chris, can you handle this stuff?

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

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

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

Bug #20196 is specifically about -display.

Move to M16 for now ...

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.

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

Move to M20 target milestone.

*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com) 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 nobody@mozilla.org) Anyways, sorry again for spam. If you really get annoyed, I'm usually available in #mozilla on IRC for torture.

->Cmd Line

nav triage team: [nsbeta3-]

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

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.

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 phil@ipal.net 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.

Marking nsbeta1- bugs as future to get off the radar

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

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

I am switching groups, and am turning this over to nobody@mozilla.org for a new owner.

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

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

This appears to block tracking bug 33378.

Yes it does - thank you. Gerv

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

adding my email to cc list.

taking bug

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.

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

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

applies to current trunk & uses XParseGeometry (thus only works on X11 platforms, which is probably OK) still doesn't work.

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 mozilla-unix@mozilla.org, 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.

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.

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?

bugs w/o patches -> NEW

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

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?

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.

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?

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.

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.

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)

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

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.

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

raul@cantara.com: if you write a patch soon, it'll have a chance of being fixed soon. how's the patch going?

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

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

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

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

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

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

Possibly won't fix per Bug 324137

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?

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

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.

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.

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?

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.

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.

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.

Weak. Very weak.

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.

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

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.

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?

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.

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

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?

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.

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.

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

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.

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.

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

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

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

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.

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.

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.

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

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.

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

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.

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

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.

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