mozilla

Revision 167508 of window.open

  • Revision slug: Talk:Document_Object_Model_(DOM)/window.open
  • Revision title: window.open
  • Revision id: 167508
  • Created:
  • Creator: Wladimir_Palant
  • Is current revision? No
  • Comment /* Some general comments */

Revision Content

This page was massively rewritten and submitted by GT in April 2005. (The original page is )

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

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)

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)

  • 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)

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.

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>
<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>
<ul><li> 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. --<a href="User:GT">GT</a> 16:33, 5 Jun 2005 (PDT)
</li></ul>
<p>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 <i>internal</i> popup blocker blocks it (btw. Opera returns some fake window object instead). Note, it's "<i>the</i> popup blocker", not "<i>a</i> 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... --<a href="User:Wladimir_Palant">Wladimir Palant</a> 18:01, 6 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. --<a href="User:Nickolay">Nickolay</a> 08:40, 11 Apr 2005 (PDT)
</li></ul>
<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 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><p>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. --<a href="User:Wladimir_Palant">Wladimir Palant</a> 16:50, 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 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. --<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 <span class="plain">&lt;object&gt;...&lt;/object&gt;</span>) 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)<span class="plain">&lt;kbd&gt;...&lt;/kbd&gt;</span> and (b)<span class="plain">&lt;abbr title="Descriptive info"&gt;...&lt;/abbr&gt;</span> 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- 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) 
</p><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>
Revert to this revision