mozilla

Revision 167499 of window.open

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

Revision Content

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

Some comments

I have made some minor changes to the page, including:

  • Changed "New, then Navigator Window from the File menu." to corresponding Firefox menu sequence.

Since mozilla.org is focusing on developing Firefox, then I have no problem with such change. GT

  • 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

  • Changed "(except titlebar, close and hotkeys which are always yes)". They are by default yes, as was correctly specified on the original page.

No problem with that. GT

  • Removed duplicate links to "user.js file". Duplicate links are distracting.
  • 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

These are things I would like to change or get some explanations:

  • Is there really useful to list all Gecko-based browsers in "Supported in"? I'd just write "Gecko X.Y". Also... NS 4.x? Come on!

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

Personally, I wish NS 4 would not be used by anyone. It's a browser which was designed around march 1996 (9 years ago) with the first beta released on december 1996. Originally, it was agreed (otherwise, I wanted) to create a document which would cover all known windowFeatures. In my mind, NS 4.x means poor, weak, buggy CSS support, poor, weak, buggy HTML 4 support, DOM 1, etc. So, if we all agree that explaining hotkeys, copyhistory, screenX, screenY is not needed nor welcomed in such document, then we should not mention NS 4 anywhere in that document. The only purpose of mentioning NS 4 in my mind (originally) was because I needed to explain what hotkeys, copyhistory, screenX, screenY were doing as windowFeatures. GT

Addendum: I removed references to NS 4.x everywhere (including hotkeys, copyhistory) GT

  • Is "text/javascript" the recommended mime type for JS? (it was the same on the original page, just wondering)

Yes. GT

  • Why remove deprecated from screenX/Y features?

I may have confused at some point "deprecated" with "not supported" in my mind somewhere. Agreed. I added "deprecated" to screenX/Y. GT

  • 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 mix 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.

  • "{{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?
  • About modal on recent mozilla release versions - are you sure?

My trunk build doesn't allow the parent window to be focused as well. Try "open("about:","","modal");" in JS Console.

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

  • "{{mediawiki.external('copyhistory feature')}} Always implemented in Mozilla-based browsers." ?? It is not implemented, right?

The document says that "the location bar history (which lists the sites in the location bar drop-down list) of the parent window is copied and available in the new secondary window". I tested+verified and confirm this again with my interactive meta demo-testcase. So, copyhistory feature as described is implemented (FF 1.0.2). OTOH, Ctrl+H and popping up the history file in the sidebar is not. I will try+test+verify with a recent Mozilla 1.8b2 trunk build in the next few days. GT

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

Hi Nickolay...this page is only partially finished at the moment -- I'm migrating it in for GT. Once it's finished (today/tomorrow?) I'll get GT to look over your comments. I have to get him to OK the markup as it is :)

dria 11:52, 11 Apr 2005 (PDT)

  • I don't think we should decorate something that isn't a variable with <var>...</var>. --Wladimir Palant 20:32, 3 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)

Corrections done in all related/relevant documents:

1- "else if(previousURL != strUrl)"

is now

"else if(previousUrl != strUrl)"

2- "he added the margins applied to the root element in MSIE 6 which is 15 pixels for left margin, 15 pixels for the right margin, 10 pixels for the top margin and 10 pixels for the bottom margin."

is now

"he added the margins applied to the root element in MSIE 6 which is 15 pixels for top margin, 15 pixels for the bottom margin, 10 pixels for the left margin and 10 pixels for the right margin."

3- The image

FirefoxChromeToolbarsDescription7.gif 920 wide x 676 high

has been replaced with

FirefoxChromeToolbarsDescription7a.gif 840 wide x 620 high

4- The quality of the semantic of markup of the document has been improved everywhere possible with the help of www.wave.webaim.org. Eg: there were many <b>...</b> which could better be replaced with <strong>...</strong>.

In wiki we usually avoid using <b> or <strong> in favor of '''bold'''. --Nickolay 15:39, 19 Apr 2005 (PDT)

5- I changed

FirefoxInnerVsOuterHeight.gif image (118 KB, 862px wide)

for

FirefoxInnerVsOuterHeight.png image (48 KB, 738px wide).

6- I created intra-page navigation anchors and links with

<span id="anchor">...</span>

(...)

[[#anchor]]

7- I changed <span id="top">...</span> to <span id="topS">...</span> to avoid conflicting with <a name="top" id="contentTop"></a>

GT 18:57, 26 Apr 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 (1)<kbd>...</kbd> and (2)<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- 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 (2) still needs to be fixed.
5. Anchors: [[#anchor]], anchors are automatically created for sections and can also be created with <span id="anchor"></span>.
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.

GT 19:30, 19 Apr 2005 (PDT)

Description of the fullscreen option

I fixed some mistakes in the section on fullscreen. However, it still needs to be said there what the option actually does, apart from annoying users. And 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).

--Wladimir Palant 17:47, 3 Jun 2005 (PDT)

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_comments"> Some comments </h3>
<p>I have made some minor changes to the page, including:
</p>
<ul><li> Changed "New, then Navigator Window from the File menu." to corresponding Firefox menu sequence.
</li></ul>
<p><i>Since mozilla.org is focusing on developing Firefox, then I have no problem with such change. GT</i>
</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</i>
</p>
<ul><li> Changed "(except titlebar, close and hotkeys which are always yes)". They are <i>by default</i> yes, as was correctly specified on the original page.
</li></ul>
<p><i>No problem with that. GT</i>
</p>
<ul><li> Removed duplicate links to "user.js file". Duplicate links are distracting.
</li><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><p>These are things I would like to change or get some explanations:
</p>
<ul><li> Is there really useful to list all Gecko-based browsers in "Supported in"? I'd just write "Gecko X.Y". Also... NS 4.x? Come on!
</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><p><i>Personally, I wish NS 4 would not be used by anyone. It's a browser which was designed around march 1996 (9 years ago) with the first beta released on december 1996. Originally, it was agreed (otherwise, I wanted) to create a document which would cover all known windowFeatures. In my mind, NS 4.x means poor, weak, buggy CSS support, poor, weak, buggy HTML 4 support, DOM 1, etc. So, <b>if we all agree that explaining hotkeys, copyhistory, screenX, screenY is not needed nor welcomed in such document, then we should not mention NS 4 anywhere in that document</b>. The only purpose of mentioning NS 4 in my mind (originally) was because I needed to explain what hotkeys, copyhistory, screenX, screenY were doing as windowFeatures. GT </i>
</p><p><i>Addendum: I removed references to NS 4.x everywhere (including hotkeys, copyhistory) GT</i>
</p>
<ul><li> Is "text/javascript" the recommended mime type for JS? (it was the same on the original page, just wondering)
</li></ul>
<p><i>Yes. GT</i>
</p>
<ul><li> Why remove <i>deprecated</i> from screenX/Y features?
</li></ul>
<p><i>I may have confused at some point "deprecated" with "not supported" in my mind somewhere. Agreed. I added "deprecated" to screenX/Y. GT </i>
</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 mix 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.</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><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>
</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 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><a href="User:Wladimir_Palant">Wladimir Palant</a> 20:32, 3 Jun 2005 (PDT)
</li></ul>
<ul><li> <i>"{{mediawiki.external('copyhistory feature')}} Always implemented in Mozilla-based browsers."</i> ??  It is <i>not</i> implemented, right?
</li></ul>
<p><i>The document says that "the location bar history (which lists the sites in the location bar drop-down list) of the parent window is copied and available in the new secondary window". I tested+verified and confirm this again with my interactive meta demo-testcase. So, copyhistory feature as described is implemented (FF 1.0.2). OTOH, Ctrl+H and popping up the history file in the sidebar is not. I will try+test+verify with a recent Mozilla 1.8b2 trunk build in the next few days. GT</i>
</p><p>Also 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)
</p>
<dl><dd> Hi Nickolay...this page is only partially finished at the moment -- I'm migrating it in for GT.  Once it's finished (today/tomorrow?) I'll get GT to look over your comments.  I have to get him to OK the markup as it is :)
</dd></dl>
<p><a href="User:Dria">dria</a> 11:52, 11 Apr 2005 (PDT)
</p>
<ul><li> 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 href="User:Wladimir_Palant">Wladimir Palant</a> 20:32, 3 Jun 2005 (PDT)
</li></ul>
<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><b>Corrections done in all related/relevant documents:</b>
</p><p>1-
"else if(previousURL != strUrl)"
</p><p>is now
</p><p>"else if(previousUrl != strUrl)"
</p><p>2- "he added the margins applied to the root element in MSIE 6 which is 15 pixels for left margin, 15 pixels for the right margin, 10 pixels for the top margin and 10 pixels for the bottom margin."
</p><p>is now
</p><p>"he added the margins applied to the root element in MSIE 6 which is 15 pixels for top margin, 15 pixels for the bottom margin, 10 pixels for the left margin and 10 pixels for the right margin."
</p><p>3- The image 
</p><p>FirefoxChromeToolbarsDescription7.gif 920 wide x 676 high 
</p><p>has been replaced with
</p><p>FirefoxChromeToolbarsDescription7a.gif 840 wide x 620 high 
</p><p>4- The quality of the semantic of markup of the document has been improved everywhere possible with the help of www.wave.webaim.org. Eg: there were many &lt;b&gt;...&lt;/b&gt; which could better be replaced with &lt;strong&gt;...&lt;/strong&gt;.
</p>
<dl><dd>In wiki we usually avoid using <span class="plain">&lt;b&gt; or &lt;strong&gt; in favor of '''bold'''</span>. --<a href="User:Nickolay">Nickolay</a> 15:39, 19 Apr 2005 (PDT)
</dd></dl>
<p>5- I changed 
</p><p>FirefoxInnerVsOuterHeight.gif image (118 KB, 862px wide) 
</p><p>for 
</p><p>FirefoxInnerVsOuterHeight.png image (48 KB, 738px wide).
</p><p>6- I created intra-page navigation anchors and links with 
</p><p><span class="plain">&lt;span id="anchor"&gt;...&lt;/span&gt;</span>
</p><p>(...)
</p><p><span class="plain">[[#anchor]]</span>
</p><p>7- I changed 
<span class="plain">&lt;span id="top"&gt;...&lt;/span&gt;</span> 
to
<span class="plain">&lt;span id="topS"&gt;...&lt;/span&gt;</span> 
to avoid conflicting with 
<span class="plain">&lt;a name="top" id="contentTop"&gt;&lt;/a&gt;</span>
</p><p><a href="User:GT">GT</a> 18:57, 26 Apr 2005 (PDT)
</p><p><br>
<b>Corrections or improvements to do or possible suggestions:</b>
</p><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 <span class="plain">(1)&lt;kbd&gt;...&lt;/kbd&gt;</span> and <span class="plain">(2)&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-
Some anchors present in the original document are missing. I don't know how to create anchors with wiki.
</p><p>--<a href="User:GT">GT</a> 14:10, 12 Apr 2005 (PDT)
</p>
<dl><dd>3. Looks like it's fixed, although (2) still needs to be fixed.
</dd><dd>5. Anchors: <span class="plain">[[#anchor]]</span>, anchors are automatically created for sections and can also be created with <span class="plain">&lt;span id="anchor"&gt;&lt;/span&gt;</span>.
</dd></dl>
<dl><dd> Also, as an extensions developer, I'm a bit concerned that this page is focused on web pages authors. Base <code>window.open()</code> documentation also applies to extensions, and IMHO it is much more appropriate to use it in chrome code, than in webpages.  --<a href="User:Nickolay">Nickolay</a> 15:39, 19 Apr 2005 (PDT)
</dd></dl>
<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><p><a href="User:GT">GT</a> 19:30, 19 Apr 2005 (PDT)
</p><p><b>Description of the fullscreen option</b>
</p><p>I fixed some mistakes in the section on fullscreen. However, it still needs to be said there what the option actually does, apart from annoying users. And 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).
</p><p>--<a href="User:Wladimir_Palant">Wladimir Palant</a> 17:47, 3 Jun 2005 (PDT)
</p>
Revert to this revision