User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.15) Gecko/20080705 BonEcho/2.0.0.15 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.15) Gecko/20080705 BonEcho/2.0.0.15 Firefox fails to obey the 'geometry' X resource(s) that Netscape 4 obeyed, as I stated in comments to bug #20573 starting in 2002. The geometry resource is supposed to control the size and placement of all new document windows created by the browser. The impetus for this bug report is the effective termination of bug #20573 and opening of new bug reports related to it. This bug does differ from that one, and I probably should have filed a separate bug back in 2002. I had depended on the geometry resource for years. Then, I have depended on a proof-of-concept patch to the source that does a pretty good job. I'll continue to use the source patch as long as I can keep it working. I'll attach the current version of the patch. Reproducible: Always Steps to Reproduce: 1.Set 'geometry' resource(s) for all conceivable variations of mozilla, gecko, etc. Observe that similar resources are obeyed by xterm and other X clients. 2.Start Firefox. 3.Observe that Firefox has failed to obey the resource and has opened at a semi-random location on the screen. Actual Results: Firefox document windows open in semi-random locations as if the geometry resources was not set. Expected Results: Firefox should obey the X resources as Netscape did and basically all other X clients do.

This is the current edition of the patch I applied to Firefox 2.0.0.15 source just the other day. I have been using this patch in essentially its current form since 2005.

I modified the proof-of-concept patch to use -geometry argument in the cmd line.

It seems that Mozilla (I use SeaMonkey) has /some/ internal way of controlling its window geometry since it remembers its previous state. So couldn't there be at least a pref setting the geometry at startup? (Also, could someone tell me where this previous state is stored, so that I could make a script overwriting these data when I launch the browser?)

I found the answer to my last question : the geometry of every window (mail, navigator, history...) is stored in localstore.rdf. Then I wrote a small wrapper script that edits the values with sed before launching seamonkey. I guess the values could be obtained from xrdb... It's probably dirty but allows to "set" a pref for any kind of Mozilla window.

LL, can your method of modifying localstore.rdf cause Firefox to open all new primary document windows (other than pop-ups) in one specific location, even if another main document window has been manually moved elsewhere after it became visible, and even new windows created by running the 'firefox' command again? If so, that would probably be better than my proof-of-concept patch. It wouldn't require compiling each new Firefox version from source. Giuseppe, I like your modification to use -geometry.

You should ask for review of your patch http://developer.mozilla.org/en/Getting_your_patch_in_the_tree

Kevin, thanks for the URL. The patch (at least the form I have been using) has some side effects and is not production worthy. Also, with a full-time job and a long, painful commute, I can't take the time to go through the prescribed testing process.

(In reply to comment #5) > LL, can your method of modifying localstore.rdf cause Firefox to open all new > primary document windows (other than pop-ups) in one specific location, even if > another main document window has been manually moved elsewhere after it became > visible, and even new windows created by running the 'firefox' command again? (I use Seamonkey but I guess there's no difference.) 1) Some testing seems to show that Mozilla keeps in memory the last state (geometry, column widths...) of all kinds of windows, but writes it down to localstore.rdf only on quitting. So, when you open a new window in a running Mozilla, it doesn't read localstore.rdf and my script has no effect. Same thing when entering the command again since the script in /usr/bin checks for an already running instance. 2) Question: in this latter script there are "commands" like: xfeDoCommand(openBrowser) Maybe such commands have options we could use? Do you know if/where we can find a list and description of them? 3) In localstore.rdf there are tags like <NC:persist RDF:resource="chrome://navigator/content/navigator.xul#main-window"/>. I'll try to see if they have any effect on our problem. 4) Mozilla doesn't honor the screenX= and screenY= lines in localstore.rdf, which record the window position. Also, one cannot force a dimension to be greater than the screen size. Maybe the sizemode="normal" tag is involved, but I don't know to what other values it can be set.

(In reply to comment #8) > Some testing seems to show that Mozilla keeps in memory the last state > (geometry, column widths...) of all kinds of windows, but writes it down to > localstore.rdf only on quitting. Not very important but apparently the geometry is saved periodically, not only at closing. Indeed, the save seems to be handled in Firefox by a file named nsSessionStore.js (couldn't find it for SeaMonkey), where comments tell the state is saved at fixed intervals + when quitting. Anyone to try patching this JS? > 3) > In localstore.rdf there are tags like <NC:persist > RDF:resource="chrome://navigator/content/navigator.xul#main-window"/>. I'll try > to see if they have any effect on our problem. Killing this line makes Mozilla ignore the stored geometry at startup (it uses some default). It also creates back this line. > 4) > Mozilla doesn't honor the screenX= and screenY= lines in localstore.rdf, which > record the window position. Also, one cannot force a dimension to be greater > than the screen size. Maybe the sizemode="normal" tag is involved, but I don't > know to what other values it can be set. Found there are "maximized" and (not tested) "minimized". Killing "sizemode=..." has no effect. The fact that stored position is not used, whereas stored dimensions are, is all the more strange as both are handled the same way in nsSessionStore.js. Does this deserve a bug filing? Last, is there a way to change this bug from Product:Firefox to something more general?

1) What are people editing in localstore.rdf? So far nothing I have changed (like navigator.xul#main-window) has had any effect whatsoever. 2) As for a more general bug, there is already 20573 (Core) which looks like basically the same thing.

Bug report 20573 (https://bugzilla.mozilla.org/show_bug.cgi?id=20573) is very similar. If you look closely, you will see that I contributed a few attachments and several comments to that bug report before I filed this one. Number 20573 was focused on the -geometry command line option. It was argued that the -geometry option applied only to the first window and not to all future windows. Also, it was never substantiated that older Netscape browsers applied the -geometry option to all browser windows to be opened in the future. According to comment #74 to bug number 20573, the -geometry command line option will never be implemented for Firefox. This bug report focuses on the 'geometry' X resource (as in xrdb, .Xdefaults, and so forth). That resource _WAS_ obeyed by older Netscape browsers, and it _DID_ apply to all browser windows (to be opened in the future). The reason I filed this one was to have some hope that the decade-old functionality of the old Netscape browsers might actually someday be implemented in Firefox.

All Raul said was that he wouldn't be fixing it, not that it would never be fixed. I try to to remain optimistic in spite of the extreme age of this bug and the fact that it annoys me every single time I start up my browser.

(In reply to comment #10) > 1) What are people editing in localstore.rdf? So far nothing I have changed > (like navigator.xul#main-window) has had any effect whatsoever. For me it has, when I *launch* Seamonkey (not when I open a new window). I have this: <RDF:Description RDF:about="chrome://navigator/content/navigator.xul#main-window" height="1010" width="1000" sizemode="normal" screenX="6" screenY="4" /> and changes to height or width are honored. Of course one must not have sizemode="maximized" which overrides size settings...

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.

Not sure what component this should be under but it definitely isn't shell integration. Over to embedding -> gtk since the code being worked on it under embedding and this is a bug on Linux.

suggest combining with #20573 per discussion there. btw, i don't know why this is marked "unconfirmed". it is undoubtedly true that firefox/seamonkey do not obey the geometry resource, and it is a drag!

Bug report #20573 focuses on the command-line option, which only affects the first main window created by the command. In contrast, the X resource is supposed to affect all main document windows--which is what it did in Netscape 4.x. This report was filed as a _result_ of discussion about #20573, particularly the comment that #20573 was probably never going to be fixed. Combining the two would put the situation back where it was before this one was filed.

Actually the command line option doesn't affect anything at all, and neither does the resource. So they both do the same thing, and both are broken. After ten years I think we should forget what they used to do in Netscape and instead focus on what they should do in Firefox (and friends). In X applications, options are normally expressed as resources internal to the application. They have a set of defaults that can be overridden by resources set by the user, and these can in turn be overridden by command line options. So at this point I would say these are all the same bug. I suggested combining the bugs because I thought that might give them more votes and therefore higher priority. After all these years I just thought it might be worth trying. I'm open to suggestions. Now that I think about it, maybe we need to file a new bug for "there is no way to specify the geometry of the browser window." This is certainly a bug, and is subtly different from both "-geometry command line option doesn't work" and "geometry resource doesn't work."

Actually, in X applications, things like geometry are supposed to be pulled from the X resources database based on the user's .Xresources file and perhaps system-level application defaults files. My concern with funneling the older bugs into the new one (#492194) with the more general description is the developers could easily say that creation of a new mechanism to specify the geometry of the browser window is an enhancement request rather than a bug, and it's easier to blow off enhancement requests than bug reports. With the -geometry command line option and the geometry X resource, we can point out that Netscape honored those accepted standards, and so Firefox's failure to honor them is indeed a bug rather than an enhancement. Also, there could be some level of infrastructure around to handle the old standard mechanisms that just needs to be fixed, while making up a whole new mechanism from scratch would likely take much more work.

This bug may be older than we think. Here is an exchange I had with Marc Andreessen in July 1993: Date: Tue, 6 Jul 93 18:24:03 -0500 From: marca@ncsa.uiuc.edu (Marc Andreessen) > By the way, xmosaic also seems to ignore the geometry resource. We use an unmanaged toplevel widget to parent the multiple independent document view windows, so the geometry resource is applying to it. The defaultWidth and defaultHeight resources might help you here.

I guess I forgot to mention it at the time, but I did open a new bug #492194, "There is no way to specify browser window geometry at run time." So after 17 years is it time to close this as "WONTFIX?"

If the developers wish to acknowledge that they have no intention to support basic, important functionality that was supported by versions of Netscape many years ago along with essentially every other X Window System client I'm aware of, then WONTFIX would be appropriate. It might provide me just enough motivation to find another browser--maybe one that doesn't get 2-4X slower with each new major release. For now, I'm limping along, working around this bug by using the Devilspie program and am looking at a major investment in faster hardware made necessary largely by Firefox's exponentially increasing slowness.

I just learned that the "-width" and "-height" options have apparently been re-instated, although the correponding bugs (bug #450852, bug #50201, bug #20573) haven't been closed or even commented on, and "firefox --help" doesn't list them. That doesn't give me complete control over the geometry but it's a start.

I tried ./firefox -height 800 -width 600 on Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre, Firefox opened maximized. Where did you hear that -height or -width was implemented?

It's working for me and at least one other user. See bug #50201. I don't know when it started working because I gave up on this ever being fixed about five or six years ago.

Are you sure it's actually using the command-line options? Without those options, Firefox is pretty good at remembering the last window size and using that when it starts again. If you use the same numbers on each attempt, it might falsely appear to be working.

Yes.

I'm not sure why this is marked as unconfirmed. It has most definitely been confirmed many times. Please give users control over where their applications open.

I'm planning a 20 year anniversary party for this bug on July 6, 2013. Please plan to attend. Maybe we could celebrate by marking it "confirmed."

(In reply to comment #29) > I'm planning a 20 year anniversary party for this bug on July 6, 2013. > Please plan to attend. Maybe we could celebrate by marking it "confirmed." RSVP: Attending

"Me too." I don't know why all the new programs/developers are casually throwing away all the ancient and incredibly useful X options, like geometry. They are so uber-easy to implement. Why doesn't someone here (me?) just implement a --geometry option and get the !@$! patch accepted?

Trevor, I sincerely wish you success with the effort to get a patch accepted. I tried, inadvertently ticked off the lawyers, and failed. Also, based on discussion on the topic, it appears the support for the option would have to come from GTK rather than from Firefox itself. Please note that this report is concerned with the geometry _RESOURCE_, not the command-line option. The command-line option is the subject of bug #20573. Based on the discussion on the topic, it appears the -geometry command-line option affected _only_ the first window created. The geometry resource, on the other hand, affected _ALL_ windows a browser process would ever create.

Remind me again, why is this bug marked "unconfirmed"? How do we get it marked "confirmed"?

Embedding: GTK Widget isn't a thing, closing.

The component to which this bug report was filed _was_ a valid component at the time. From a user perspective, that's a pretty shallow excuse for throwing into the trash heap a valid bug report about missing basic functionality implemented by essentially every X client for decades. Just as well, though, because the Devilspie program works rather well. Also, if this were the most major problem Firefox had, it would be a much brighter day. It's time to go browser shopping.