This page was massively rewritten and submitted by GT in April 2005. (The original page is )
Feature arguments and customized Firefox menubars
I like to heavily customize my Firefox installs (220.127.116.11, Linux) so that the navigational buttons, drop-down menus, location field, and search field are all moved to what was originally just the menu bar. I discovered that when using
window.open, (and providing at least one feature argument) I wasn't able to get the location field to show unless I specified both
location. This doesn't really seem like a bug to me, but probably should be mentioned here. Any thoughts on where in this large page it should go? --Jarsyl 01:35, 8 March 2007 (PST)
Some general comments
- Made it use italics more consistently.
Wait a min. The document was using <var> markup for each occurences of variable identifiers and variable values; these were removed and replaced with embedding <i>....</i>. The <var> may be rendered as italic text in some (many?) visual browsers but it is not rendered as such in other user agents. So this will have be redone entirely, I fear. GT
Addendum: I changed the markup from italic to var or em and from bold to strong wherever appropriate. GT
- Is there really useful to list all Gecko-based browsers in "Supported in"? I'd just write "Gecko X.Y".
Most people do not know what is the release or revision version of browsers, say, like Gecko 0.9.4 or Gecko 1.2.1, but they will relate to NS 6.x or even NS 7.x. I am in the process of uploading icons of browser versions. GT
- I don't think we should decorate something that isn't a variable with <var>...</var>. --Wladimir Palant 20:32, 3 Jun 2005 (PDT)
My understanding is that variable identifiers and variable values should be embedded into <var>...</var>. Like I replied to Nickolay, the document was using <var> markup for each occurences of variable identifiers and variable values http://www.mozilla.org/contribute/writing/markup#computers GT 13:47, 5 Jun 2005 (PDT)
- Wladimir: in "Return value and parameters" section, you added "it will be null if the call didn't succeed to open the window (e.g. it was blocked by the popup blocker)." but according to Lasse R. Nielsen, "Some popup blockers work at the operating system level, and automatically close all new windows created by a browser. The call to window.open succeedes, but the window disappears before the user can see it." http://www.infimum.dk/HTML/JSwindows.html#ref_3_5 So the call may succeed, the object reference may but the window may be closed, "blocked" very shortly after being opened. --GT 16:33, 5 Jun 2005 (PDT)
We are not talking about "some popup blockers" here, especially not about the ones working at operating system level, right? We don't care about the operating system and whatever it (or the user just as well) might do to our windows. We are talking about the return value of window.open() and AFAIK there is only one case where it doesn't return an object - if the one and only Mozilla's internal popup blocker blocks it (btw. Opera returns some fake window object instead). Note, it's "the popup blocker", not "a popup blocker". But if you think this isn't clear enough, we might clarify that it is blocked by "Gecko's popup blocker". Popup blockers would be worth a separate article... --Wladimir Palant 18:01, 6 Jun 2005 (PDT)
Wladimir: 1- This document is not just only for Gecko-based browsers; it aspires to be a cross-browser reference. Of course, I originally wanted it to be more substantial, more thorough for Mozilla-based browsers. 2- There are many popup blocker softwares in use out there; a web author just can not assume that there is only browser built-in popup blockers. 3- If the reference is null, it does not necessarly implies that there is a popup blocker being active or that the browser built-in popup blocker is active. The reference could be null for other reasons. All it should mean AFAIK is that the window.open did not succeed in opening a new window and that's it. 4- Very often in web programming newsgroups, you get questions where people ask how to detect popup blocker: the final answer is that one can not reliably detect an active popup blocker. Having the reference points to null might be because of a popup blocker or because of the browser built-in popup blocker but AFAIK it might also be for other reasons. 5- In the FAQ, I say "(...) verify that WindowObjectReference.closed return value is false but this is not a reliable way to detect presence of an active popup blocking software." 6- I think this document should stay away as much as possible from popup blocking issues/matters. Above 95% of all webpages using window.open() out there code poorly or mindlessly links with window.open(), break accessibility of links, abuse in all sorts of ways window.open() calls, try to over-excessively control users (or browser windows) in all sorts of ways, etc.. and that is what the document ambitions to counter, to cure somehow ... and not on how to counter or work around the defensive measures of users or browsers. --GT 13:00, 8 Jun 2005 (PDT)
This discussion is getting silly. The sentence is an example of the reasons why a browser might return something other than a Window object. It is meant to make clear that one should always check the return value instead of relying on getting a Window object. It doesn't say that the popup blocker is the only reason causing a null return value (though I don't know of any other). It doesn't say how to prevent it (however, the principles of Gecko's popup blocker need to get documented somewhere else). It also implies that this statement is only valid for the browser's internal popup blocker. We don't and we can't deal with every type of popup blocker here! As to the FAQ, I just haven't got there yet. I corrected this sentence now, you shouldn't insinuate that one sometimes can use window.closed in order to detect an external popup blocker - one never can. And popup blocking really isn't related to the question you are answering there. --Wladimir Palant 19:03, 8 Jun 2005 (PDT)
- GT: you added "The window creation and the loading of the referenced resource are done asynchronously." Do you really feel like repeating the same thing I said with the previous two sentences all over again? I did't use the term "asynchronously" for a reason, it doesn't mean anything to an average web developer. --Wladimir Palant 19:03, 8 Jun 2005 (PDT)
- "First check for the existence of the window object reference of such window and if it exists and if it has not been closed" -- that's assumes the programmer stores the window reference in exactly the same way as in examples, which he doesn't have to. We must change this to a more correct formulation, something like "If you have the reference to the window object and it isn't closed". --Wladimir Palant 19:03, 8 Jun 2005 (PDT)
- I don't get the answer to "How do I force a maximized window?" Maybe "minimized" was meant here? --Wladimir Palant 19:03, 8 Jun 2005 (PDT)
- The answer to the question "How do I turn off window resizability or remove toolbars?" absolutely misses the question. It should be answered in a short sentence at least before giving the reader a lecture on usability. This is in the best interests of both the author and the readers. :) --Wladimir Palant 19:04, 8 Jun 2005 (PDT)
- Same thing with the question "How do I resize a window to fit its content?" - it isn't answered. If this question is in the FAQ it needs answering, this one comes pretty often namely and it isn't trivial. Problem is that for lots of applications you need to resize the popup windows after opening them and a lecture on how users can prevent you doing that doesn't help here. If I were a starting web programmer and I read this trying to find a solution for window resizing, I would never come back here. Btw, last I checked sizeToContent() was broken and doesn't help with non-Gecko browsers anyways. --Wladimir Palant 19:03, 8 Jun 2005 (PDT)
- "Mozilla-based users" LOL :) --Wladimir Palant 19:03, 8 Jun 2005 (PDT)
- I have to add on to the subject of resizing a window to fit its content. I think this orthodoxy surrounding tabbed browsing is getting out of hand - my website utilizes popups in a responsible fashion, both to keep the number of pages open low (by reusing windows) and by ensuring the maximum screen space is available for the content (removing excess toolbars, resizing). Most of my users still have 15" screens, they are lower-level business users with older machines. Our site will become much more inconvenient when you cut the screen real estate in half with tabs, toolbar, and status bar, none of which can be disabled by default in Firefox 3 or Safari 3.1/Win. You also seem to ignore that well over 45% of users (particularly business users) out there are still using IE 6, and so their user experience will be even further diminished because of the lack of choices now offered to web programmers in the newer browsers. Talk about usability all you want, the usability for my users has just been compromised. --Stephen Weiss
window features (toolbars, functionalities, requiring priviliges)
- We should create anchors for all the features, so that it is easy to link to a particular feature, both from this page and from other pages. --Nickolay 08:40, 11 Apr 2005 (PDT)
- Is really necessary to repeat the "height" text in "innerHeight" description after saying it's the same as "height"?
Yes. Originally NS 4 was supporting height and width only. Then web developers were confused. Is height referring to the content height, the inner height of the window or to the whole window with the toolbars, chrome, to its outer height? So that's how+why Netscape created 2 other pairs of windowFeatures which were more meaningful, intuitive, self-explanatory. Even today, lots of people confuse, get mixed up: they set a value to height and expect the whole window to fit within such value. One example: see links and comments 1, 2 and 3 at bugzilla bugfile 232531 GT
Addendum: it is not absolutely necessary to repeat height text in innerHeight but then there has been many bugfiles opened by people because they thought/claim/request that innerWidth/innerHeight values should not include the vertical/horizontal scrollbar. GT
- alwaysRaised doesn't work in content script only. Works fine if you use it from chrome code (i.e. Firefox itself or extensions).
alwaysRaised at the time of writing does not work for content scripts like it should. Agreed. See bugzilla bugfile 274088. GT
- I fixed the bogus descriptions for chrome and modal. Chrome is fully supported but requires privileges now. Same thing with modal, for unprivileged scripts it is just the same as dependent (see nsWindowWatcher.cpp). The description for alwaysRaised/alwaysLowered was also wrong, the current security check comes from a patch for Mozilla 0.9, it has nothing to do with the mentioned bug. And they are very well supported in content scripts -- with the necessary privileges. --Wladimir Palant 20:32, 3 Jun 2005 (PDT)
I remember having huge difficulties with chrome (understanding it). The thing is that old Mozilla releases where supporting it without privileges. --GT 13:47, 5 Jun 2005 (PDT)
- There are still some features left that need to be mentioned: popup (window without a frame and always on top), extrachrome (hides all elements with class extrachrome, sort of a hack), centerscreen, all (combination of all window and chrome features). --Wladimir Palant 20:32, 3 Jun 2005 (PDT)
I tried to examine and investigate these other features and I couldn't make sense out of some of them. centerscreen: I gave up trying to make sense out of that one after many hours of experiment, even after email exchanges with Dan M. It worked somewhat in NS 6.2. extrachrome, popup and all: these only work with chrome code and not for secondary windows being created by web authors. If you, Wladimir, can bring light on these, that would help improve this document. --GT 13:47, 5 Jun 2005 (PDT)
centerscreen requires chrome also to be set (privileged execution of course). Then it does exactly what the name says, for both HTML and XUL documents. extrachrome also requires chrome (this one is actually very much a hack, I'm not sure it should be documented). All these options can be used by web authors -- if they sign their scripts and request privileges. And they can be used by extension developers, this reference should be targeting them as well I think. --Wladimir Palant 16:50, 5 Jun 2005 (PDT)
centerscreen is a misnomer (centers in the parent's browser viewport - not the user screen) according to Dan M.; in any cases, I never was able to make it work (except partially in NS 6.2). You are welcome to explain what all these windowFeatures (extrachrome, all, popup, centerscreen) do. When writing the document, I deliberately excluded all these (extrachrome, all, popup, centerscreen) because I was unable to verify empirically and to certify empirically what these special windowFeatures were doing.--GT 13:00, 8 Jun 2005 (PDT)
- Wladimir: I absolutely can't get the meaning of 'Certains parts of the interface stop functioning in MSIE 5.x', especially after noting that this feature works differently in IE 6.0 SP2 (btw. I don't think many people know what SV1 means).
I just updated the document and explicited what was meant with "parts of interface stop functioning". I have replaced SV1 with SP2. Because I was using a trunk build, I unexpectedly and unintentionally removed some comments in this file :( Sorry. --GT 14:57, 5 Jun 2005 (PDT)
- I added a title specification in 4 examples for the links: title="This link will create a new window or will re-use an already opened one" --GT 13:00, 8 Jun 2005 (PDT)
Corrections or improvements to do or possible suggestions:
1- Make the Firefox toolbars image narrower. Ideally, such image would not create an horizontal scrollbar on an 1024x768 scr. res.
2- Implement an image map (with <object>...</object>) of the firefox toolbars image like it is in the original document. This may not be possible in here; I do not know for sure.
3- The markup code (a)<kbd>...</kbd> and (b)<abbr title="Descriptive info">...</abbr> in the document is not rendered right now. I'm leaving the code as it is for now, hoping that eventually, such markup will be supported in wikitext.
4- As an extensions developer, I'm a bit concerned that this page is focused on web pages authors. Base window.open() documentation also applies to extensions, and IMHO it is much more appropriate to use it in chrome code, than in webpages. --Nickolay 15:39, 19 Apr 2005 (PDT)
5- I will need to compress lines of code to 66 characters or so to make comparison of different versions doable without scrolling horizontally. This will be done on the fly with changes, corrections.