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)

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.

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

"{{mediawiki.external('chrome feature supported')}} not in Firefox 1.0 and not in recent Mozilla release versions." Huh? How Tools > Options worked in Firefox 1.0 then?

I tried it (FF 1.0.2) and I could not get the parent window (JS Console) to be focused, just like yourself. Right now, I have not tried it with a 1.8b2 trunk build but will do so in the next few days. I do not know what to tell you. Each/all modal windows created in the interactive meta-demo testcase popup debugger allow its own parent-opener to be focused and, at the same time, not letting the popup get behind its own parent-opener. 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)

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 explicited what was meant with parts of interface stop functioning. I am in the process of replacing SV1 with SP2. And sorry, 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)

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)... and (b)... 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- Some anchors present in the original document are missing. I don't know how to create anchors with wiki.

--GT 14:10, 12 Apr 2005 (PDT)

3. Looks like it's fixed, although (b) still needs to be fixed.
5. Anchors: #anchor, anchors are automatically created for sections and can also be created with .

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

Revision Source

<p>This page was massively rewritten and submitted by GT in April 2005. (The original page is <a class="external" href="http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html">)
</a></p><a class="external" href="http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html">
<h3 name="Some_general_comments"> Some general comments </h3>
<p>I have made some minor changes to the page, including:
</p>
<ul><li> Made it use italics more consistently.
</li></ul>
<p><i>Wait a min. The document was using &lt;var&gt; markup for each occurences of variable identifiers and variable values; these were removed and replaced with embedding &lt;i&gt;....&lt;/i&gt;. The &lt;var&gt; 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</i>
</p><p><i>Addendum: I changed the markup from italic to var or em and from bold to strong wherever appropriate. GT</i>
</p>
<ul><li> Is there really useful to list all Gecko-based browsers in "Supported in"? I'd just write "Gecko X.Y".
</li></ul>
<p><i>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>
</p>
</a><ul><a class="external" href="http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html"></a><li><a class="external" href="http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html"> I don't think we should decorate something that isn't a variable with <span class="plain">&lt;var&gt;...&lt;/var&gt;</span>. --</a><a href="User:Wladimir_Palant">Wladimir Palant</a> 20:32, 3 Jun 2005 (PDT)
</li></ul>
<p>My understanding is that variable identifiers and variable values should be embedded into <span class="plain">&lt;var&gt;...&lt;/var&gt;</span>. Like I replied to Nickolay, the document was using &lt;var&gt; markup for each occurences of variable identifiers and variable values
http://www.mozilla.org/contribute/writing/markup#computers
<a href="User:GT">GT</a> 13:47, 5 Jun 2005 (PDT)
</p>
<h3 name="window_features_.28toolbars.2C_functionalities.2C_requiring_priviliges.29"> window features (toolbars, functionalities, requiring priviliges) </h3>
<ul><li> 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.
</li></ul>
<p>--<a href="User:Nickolay">Nickolay</a> 08:40, 11 Apr 2005 (PDT)
</p>
<ul><li> Is really necessary to repeat the "height" text in "innerHeight" description after saying it's the same as "height"?
</li></ul>
<p><i>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</i>
</p><p><i>Addendum: it is not <b>absolutely necessary</b> 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</i>
</p>
<ul><li> alwaysRaised doesn't work in <i>content</i> script only. Works fine if you use it from chrome code (i.e. Firefox itself or extensions).
</li></ul>
<p><i>alwaysRaised at the time of writing does not work for content scripts like it should. Agreed. See bugzilla bugfile 274088. GT</i>
</p>
<ul><li> <i>"{{mediawiki.external('chrome feature supported')}} not in Firefox 1.0 and not in recent Mozilla release versions."</i> Huh? How Tools &gt; Options worked in Firefox 1.0 then?
</li></ul>
<ul><li> About <i>modal</i> on recent mozilla release versions - are you sure?
</li></ul>
<p>My trunk build doesn't allow the parent window to be focused as well. Try "open("about:","","modal");" in JS Console.
</p><p><i>I tried it (FF 1.0.2) and I could not get the parent window (JS Console) to be focused, just like yourself. Right now, I have not tried it with a 1.8b2 trunk build but will do so in the next few days. I do not know what to tell you. Each/all modal windows created in the interactive meta-demo testcase popup debugger allow its own parent-opener to be focused and, at the same time, not letting the popup get behind its own parent-opener. GT</i>
</p>
<ul><li> 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. --<a href="User:Wladimir_Palant">Wladimir Palant</a> 20:32, 3 Jun 2005 (PDT)
</li></ul>
<p>I remember having huge difficulties with chrome (understanding it). The thing is that old Mozilla releases where supporting it without privileges. <a href="User:GT">GT</a> 13:47, 5 Jun 2005 (PDT)
</p>
<ul><li> 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). --<a href="User:Wladimir_Palant">Wladimir Palant</a> 20:32, 3 Jun 2005 (PDT)
</li></ul>
<p>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. <a href="User:GT">GT</a> 13:47, 5 Jun 2005 (PDT)
</p>
<ul><li> 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).
</li></ul>
<p>I explicited what was meant with parts of interface stop functioning. I am in the process of replacing SV1 with SP2. And sorry, because I was using a trunk build, I unexpectedly and unintentionally removed some comments in this file :(. Sorry. <a href="User:GT">GT</a> 14:57, 5 Jun 2005 (PDT)
</p>
<h3 name="Corrections_or_improvements_to_do_or_possible_suggestions:"> Corrections or improvements to do or possible suggestions: </h3>
<p>1- Make the Firefox toolbars image narrower. Ideally, such image would not create an horizontal scrollbar on an 1024x768 scr. res.
</p><p>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.
</p><p>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.
</p><p>4- Some anchors present in the original document are missing. I don't know how to create anchors with wiki.
</p><p>--GT 14:10, 12 Apr 2005 (PDT)
</p>
<pre class="eval"> 3. Looks like it's fixed, although (b) still needs to be fixed.
5. Anchors: <a href="#anchor">#anchor</a>, anchors are automatically created for sections and can also be created with <span id="anchor"></span>.
</pre>
<pre class="eval"> Also, 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)
</pre>
<p>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.
</p>