Closed Bug 50201 Opened 24 years ago Closed 12 years ago

-width and -height options ignored

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: bugday0420)

couldn't find an existing [open] bug on this, so... i've tried the following command-line options, all of which do nothing to change the size of the browser window (which maintains the same size from its previous session): mozilla -height 200 mozilla -width 200 mozilla -height 200 -width 200 am using today's 2000.08.24.08 opt bits on Win98. i don't have access to the linux bits today --timeless, pavlov or jrgm, could you see whether these options work at all on linux? my guess is that they won't, but ya never know. so, like if these commands aren't supposed to work as i've issued 'em, pls let me know if 1. they ain't implemented. then we should either implement 'em, or pull 'em out. 2. i'm somehow issuing the commands incorrectly. strange, but lemme know the correct way. thx!
with gramps on sabbatical, who should be the lucky owner of this bug?
Keywords: nsbeta3
Solaris8Intel build from tuesday's tip doesn't seem to use these params either.
thx, timeless.
Hardware: PC → All
Nav triage team: [nsbeta3-], leaving assigned to Don for the time being.
Whiteboard: [nsbeta3-]
methinks the fix to this might be dependent on fixes for bug 20573...
Depends on: 20573
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: helpwanted, nsbeta1-
Could this be implemented anytime soon? The company I work for is planning to use mozilla & XUL under Linux for our core borwser component, and it would be very desirable to have geometry ability from the command line.
-> law
Assignee: vishy → law
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
Since this does not seem to get resolved soon, could someone please change the reference webpage http://www.mozilla.org/quality/browser/front-end/testcases/cmd-line/ accordingly, i.e. deleted the lines involving -height and -width? (And on that occasion rename Win32 in the Unix/Linux section to Unix/Linux?) Or should I open a new bug for this?
It's interesting to note that in Debian, the -width and -height arguments work in the 1.0.0 package and in the 1.5-3 package, but not in the 1.6-5 package.
This bug applies to latest 1.7.6 on WinXP and Linux GTK2+XFT trunk as well. Note that the following: mozilla -P profilename -height 768 -width 1024 -browser http://www.google.com will bring up a Google window 1024px wide and 768px high, but it will be chromeless in which no keyboard functions for controls, such as ctrl++, ctrl+- & ctrl+h, do anything at all.
OS: Windows 98 → All
*** Bug 238607 has been marked as a duplicate of this bug. ***
fwiw, a hack to force mozilla to have a specifc geometry (via a mozilla/init.d pluggable shell script) can be find at ftp://noc.hep.wisc.edu/pub/src/mozilla
*** Bug 323128 has been marked as a duplicate of this bug. ***
This bug exists in the Firefox/1.5.0.4 (OpenSuSE Linux): Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.0.4) Gecko/20060527 SUSE/1.5.0.4-1.3 Firefox/1.5.0.4 My tests show that MOST commandline options are ignored, -width, -height, -ProfileManager, -P <profile>. This occurs when calling firefix and also when calling firefox-bin directly. When firefox exits, the following content gets written to localstore.rdf : <RDF:Description RDF:about="chrome://browser/content/browser.xul#main-window" width="861" height="946" screenX="411" screenY="0" sizemode="maximized" /> (I hope I copied the correct portion out of the file!) This is irrespective of the current window geometry. Hope this helps, nts.
This is, at least in part, related to Bugzilla Bug 317903. There it is explained that profile commandline options are ignored unless the environment variable MOZ_NO_REMOTE is set to 1 (tcsh: "setenv MOZ_NO_REMOTE 1", bash: "export MOZ_NO_REMOTE=1"). This might also affect other commandline options. Setting MOZ_NO_REMOTE to 1 has helped in my case to display and enable profiles. Personally, I think that a warning message should appear to explain that commandline options were ignored and what to do so that they are not! nts.
*** Bug 352328 has been marked as a duplicate of this bug. ***
Assignee: law → nobody
*** Bug 364729 has been marked as a duplicate of this bug. ***
MOZ_NO_REMOTE=1 has no effect MOZ_NO_REMOTE=1 firefox -height 500 -width 400 has no effect.
I confirm that: export MOZ_NO_REMOTE=1 firefox -height 800 -width 600 ...has not effect. Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
per bug 444319, turning this into a seamonkey bug.
Component: Cmd-line Features → MailNews: General
Priority: P3 → --
Product: Core → SeaMonkey
QA Contact: bugzilla
Target Milestone: Future → ---
Assignee: nobody → general
Component: MailNews: General → General
QA Contact: general
suggest combining with #20573 per discussion there.
Assignee: general → nobody
Component: General → Startup and Profile System
Product: SeaMonkey → Toolkit
QA Contact: general → startup
Whiteboard: bugday0420
Has this been fixed? It's working for me now, but is undocumented as far as I can tell, and doesn't show up in "firefox --help." So is it working by accident or by design?
I can confirm that it is working in Mozilla Firefox 4.0b6 and that it does not show up in the -help output. This is on a 32-bit Linux system.
Yeah they aren't shown anywhere anymore, so no reason to believe they would work either. WFM.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whops, indeed they are working. Just not documented.
You need to log in before you can comment on or make changes to this bug.