Hi Chris, very probably, you are not describing a bug, but the following feature.
Chris wrote on Mon, Mar 23, 2009 at 02:15:10PM +1100: > When I start firefox (3.0.6) from the xterm shell, I get two firefox > starting at the same time. Very probably, you are not getting two firefox processes, but one firefox process managing two windows. To check this, run $ ps ax | grep firefox-bin > If I close one of them (by doing File - Exit), By chance, i still have the somewhat oldish firefox 3.0.6 installed on a 4.5-current i386 box. Here, the file menu doesn't contain an "Exit" menu entry. > it closes both of them. When i do "File - Quit", i get a popup window "Do you want Firefox to save your tabs and windows for the next time it starts? [Checkbox] Do not ask next time Button: Quit Button: Cancel Button: Save and Quit" Maybe you checked the checkbox and clicked "Save and Quit"? When doing that, i can reproduce the behaviour you describe. > I have the same behavior from two > different window managers: awesome and scrotwm. Probably, what you describe has nothing to do with the operating system or the window manger, but with firefox itself. You can go to "Edit - Preferences - Main - Startup" and select "When Firefox starts, Show my home page". Actually, you wouldn't believe it from what the dialogue texts in the browser say: But that will revert *exactly* the effect of checking the box "Do not ask next time". I checked this by diffing the prefs.js file before and after. If you want to keep the behaviour of restoring tabs and windows on startup but just want to use only one window in the future, just click "File - Close" in one of your two windows. Now don't get me started on firefox. It has turned so damn MS-Windows-ish: Creeping featurism wherever you look, features hidden so well and in so much layers that you simply do not find most of them even when you actively search for them, almost nothing documented, incomprehensible names of features, unintellegible correspondance between UI texts and configuration option names, unsecure to insane defaults and bloat, bloat, bloat... All the same, things you really need are not available, or you need obscure plugins to achieve them. So if anybody is going to write a browser that i would like, i would probably contribute funding to allow several months of full time work. Yes, i know that a few months will hardly suffice. I would like the following: * Monolithic, fast, small and readable code; no plugins. * Secure, good privacy, high speed by default, and no way to move the global default settings away from that. * No useless knobs. No drop-down menus. No icon toolbars. * Do not bother about non-POSIX operating systems, i.e. assume that POSIX external utilities and C library calls are available. * Strict principle of not more than one HTTP request per click or ENTER. * No data ever sent across the wire without an explicit left click or ENTER. * Never reuse a tab for a different URL unless explicitely requested. Always use a new tab for each new URL. * Two URL bars, the upper showing the URL displayed in the current tab, the lower showing the URL the mouse is currently pointing at, including the TARGET tag, if any. Prominently mark POST to distinguish it from GET. The lower URL bar can also be used for keyboard input. * A delete command (d) to close the current tab. * A goto command (g) to open a new tab and set the cursor to the URL line, such that "ghttp://www.openbsd.org/<ENTER>" gets you there. * An alias command (a) to define a bookmark to the current URL, for example "aobsd<ENTER>" to make "gobsd<ENTER>" work. * Show meta-information about embedded content, not the content itself, i.e. content type (e.g. IMG), file name or URL, ALT text, size if it is large. * Per-site and per-URL configuration database, allowing things like - embedded image download (off by default) - CSS download (off by default) - frame content download (off by default) - accepting cookies (off by default) - JavaScript execution (off by default) Store this DB in plain text, easy to browse with cd, ls and vi. * Do not use any files in the user's home directory except this DB and the cache explained below. In particular, no .mozilla-like configuration directories. * When showing frames, always prominently mark the frame borders, and in the top line of each frame, always show the frame name and the current URL. * When asking about cookies, always show the full cookie content. * Always ask about HTTPS certificates, even when signed by commercial root CAs, always show the full certificate content at once, and one line stating the supporting chain of trust, if any. Require exactly one click: "Use once" or "Save". Cancel is useless as you can just close the tab. Do not try to explain what this is all about. * When interpreting JavaScript, state what the code is trying to do, i.e. display some text or control elements, follow some link, get some content, open some window, but do *not* do it. Yes, i know this is much more difficult than most of the rest. * Never ever accept any cross-domain embedded content. * By default, preview the full content of POST requests before submission. * Consistent mouse layout: - left click: activate, e.g. follow link (in a new tab, of course) - middle click: show, e.g. download and display embedded image - right click: hide, e.g. replace the image by a "useless" icon - with shift: also remeber the choice in the config DB - with alt: modified functionality, e.g. respect TARGET tag * One-key switch between source (s), rendered (r) and filtered rendered (f) view, without reloading the page, of course. Stay at the same point in the document when switching views. * Even in rendered view, show interesting meta information at the top, e.g. content type, title, generator, keywords, employed techniques; perhaps make this mildly configurable. Never use the X window title bar for anything, leave that to X. * To figure out the content type, use both the content type header and file(1). Provide a command to manually switch the content type (t). * Try to safely display any content, using appropriate filter utilities configured in /etc/mailcap, e.g. unrtf, pdftotext, antiword, strings. Never ever ask whether to download binary content to a file. * Provide a command to start an external viewer (x), e.g. xpdf. * A save command (s) to cache the current URL to disk. * Never cache anything unless explicitely requested. * When opening a new tab for a URL that is still in the cache, show the cached version if it is large (together with a warning), but reload and display the version from the Internet if the cached copy is small. * An update ("u") command to explicitely reload large URLs. * When viewing a newer version of a cached URL, highlight the changes. Allow one-key switch between highlighting and unified diff. * No difference between save and download. When downloading, do not ask for filenames, just use the normal caching tree. In case the URL is cumbersome, you are free to define an alias. Or you can use cp(1) or ln(1), if you like. * A watch command (alt-s) to save and mark as watched. * A command to check all watched URLs for changes, opening the changed ones. * In source view, easy to use junk filtering, e.g. - Right click on a font tag, and all font tags are gone. - Right click on an image tag, and all images are replaced by [IMG:filename:alt]. - Preserve this when switching back to rendered mode, even when not saving anything to the config DB. * Of course, left and middle clicks should also work in source mode. * A save config command (c) for the current tab, in case you forgot shift. * An edit config command (alt-c) for the current tab/URL. * A show headers command (h) to show received HTTP headers. * A tweak headers command (alt-h) to manipulate HTTP headers to be sent. * Perhaps a raw HTTP console with tab completion. Well, that's enough dreaming for today. Yours, Ingo
