227241 - Open new windows only upon explicit instruction (Single Window Mode) (open new-window links in tabs instead)

Status: VERIFIED DUPLICATE of bug 172962

(Firefox :: Tabbed Browser, enhancement)

Description

[Grey Nicholson (they/them)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.5) Gecko/20031007 Firebird/0.7

Firebird should have the option of a single window mode (à la TBE) built in.

Firebird version of bug 103843 (?)

Reproducible: Always

Steps to Reproduce:

Comment 1

[Jesse Ruderman]

I've heard "single window mode" mean two features:
A) Windows that the web page opens open in a new tab.
B) A, plus Ctrl+N opens a new tab instead of a new window, and all "Open ... in
New Window" commands are removed.

I am in favor of adding (A), but I am against adding (B) as a single checkbox.

Comment 2

[Grey Nicholson (they/them)]

TBE implements Single Window mode in one of two ways (configurable by the user):
1. only ever use one window (A & B)
2. open new windows only upon explicit instruction (A)

My original suggestion was for Only ever use one window. However, I think the
other option would be better, assuming it's do-able, and not as buggy as TBE's
implementation.

Comment 3

[Bob Firth]

related to bug 189313?

Comment 4

[Steffen Wilberg]

Confirming.

Comment 5

[Mike Connor [:mconnor]]

this has to be somewhere already, I know this is planned...

Comment 6

[John Lee]

I don't recall seeing anything in the roadmap nor a confirmation from any of the
devs. This is the most requested TBE feature, though.

Comment 7

[Steffen Wilberg]

Re comment 6: Dave Hyatt, the Firebird module owner, has said in
http://forums.mozillazine.org/viewtopic.php?p=144580#144580 :

As for TBE, there are some features that we'd like to implement, but in some
cases TBE has implementations that aren't desirable, e.g., the way it forces
open windows into new tabs. My understanding is that it actually lets the window
open and then it shoves it into a tab and closes the window (this also severs
the window.opener connection that is supposed to exist between the two windows).

We want to fix that at the C++ level and really make the initial window open
right in a new tab.

Some tab features that we would like to see incorporated into Firebird (patches
welcome):
(1) Ability to drag/drop to reorder tabs
(2) Ability to force windows into new tabs always (hard, anything that just
hacks JS is inadequate)
(3) Ability to drag a tab out of the tab strip and drop it into another tab
strip or to drop it on the desktop and have a new window get made

Features that we will not accept:
Tons of prefs for tabs just because you don't like our defaults (e.g., where
tabs open, where tabs close, close boxes on tabs, etc. etc.). Adding a bunch of
geeky configurability options is perfect for an extension.

Comment 8

[red.baron]

Javascript popup windows should probably be allowed to open in a new window or
else the graphics and text would be skewed.

Comment 9

[Grey Nicholson (they/them)]

“Javascript popup windows should probably be allowed to open in a new window or
else the graphics and text would be skewed.”
Clicking a javascript popup link isn't an explicit instruction to open a new
window. Besides, most JS popups look OK in tabs.

Comment 10

[Bradley Chapman (not reading bugmail, still gone but not forever)]

http://forums.mozillazine.org/viewtopic.php?t=37895

This is the thread where a signficiant portion of the MozillaZine populace voted
for the features that they wanted to have in the core from TBE. Single window
mode topped the list.

What milestone is this targeted for? Is it just a matter of writing a diff that
adds single window mode to the core, or will it take longer?

Comment 11

[Mike Connor [:mconnor]]

The goal is to implement this in C++, not javascript, so that its
faster/smoother.  If someone wants to write a patch for this, I'm sure it will
get some attention.  Keep in mind the requirement means it is part of the
backend, not in the XUL frontend, so porting stuff out of TBE won't cut it.  If
this is shared with Seamonkey, as long as it defaults off it won't really
matter, and those who'd want it in Seamonkey could always use the hidden pref.

Comment 12

[pantsgolem]

Re: comment 8 and comment 9

Ideally, javascript new windows ought to be handled the way TBE handles them
when using setting 2 as described in comment 2.  If the window it would open is
a full, normal window (i.e. just a plain window.open() call) it makes it a tab.
 If there's a window size specified, it's best to open the window as specified
by the call.

Comment 13

[Michael Moy]

There are three options in TBE and they're probably there for a reason. I prefer
option 3, always only use one window. Crazy Browser, the first tabbed browser
that I used, offered the option for everything in one window or the ability to
use more than one window.

Comment 14

[Grey Nicholson (they/them)]

Having javascripts pop up new windows should be optional; I prefer new windows
to open in tabs, regardless of their size - a bit of whitespace around the
content usually does no harm.

Comment 15

[Mike Connor [:mconnor]]

*** Bug 232955 has been marked as a duplicate of this bug. ***

Comment 16

[Ben Basson]

Re: Comment #14 and other JS open in tab comments...
Simple workaround to avoid pages being skewed or stretched to the full size of
the tabbed window is to set a containing div with explicit width and height
values that the JavaScript link requested.
Setting a border around this div, an overflow value of auto and centering it
within the screen would essentially mimmick the hehavior of a popup, but within
the framework of a tabbed browser.

Comment 17

[Michael Moy]

At the moment, TBE option #3, everything in tabs stretches things out but I've
been using that mode for a long time and it seems fine to me. I suppose that
there may be problems for some popups that rely on the screen size instead of
fixed pixel positions but I've never run into one of those. Of course I normally
see very few popups except the ones that I want.

Comment 18

[Grey Nicholson (they/them)]

(In reply to comment #16)
I like this idea. However, this throws up the problem of what to do if the
website uses links with target attributes. Should we (a) ignore a target
attribute pointing to an already-open window and open another tab; (b) open that
link in the existing tab, without the containing div; or (c) open it in the
containing div?

If (c), which seems to make the most sense, how do we go about id-ing the div as
if it were a frame? Or should we use a frame instead (which may or may not be
do-able whilst complying with standards - I believe iframe's deprecated)?

Maybe XUL could come into it, to restrict the size of the popped-up tab to the
size specified by the javascript, greying out the rest. Actually, I quite like
that idea. :)

Just thinking in type...

Comment 19

[Ben Basson]

RE: Comment #18,
As long as the correct tab is identified by the core code this should be simple
(well, simple logic anyway)...

1. User clicks a JavaScript link to spawn a popup window, which is loaded in a
tab. The following properties are obtained by the core code: 
 - Height & Width
 - How to handle overflow - i.e. scrolling or not
 - ID or name of the window.

2. Height & Width are used to create a div, as is the overflow. ID/name of the
window is added to an array, referencing which tab is used for that ID.

3a. User clicks another link which targets the previously spawned window, which
we are handling in a tab. Core code obtains the target of the link and compares
to those in array. If a suitable tab is found, Firebird reads HTML content (if
any) at the href (assuming it exists) and switches the old containing div
contents for new... The HTML would then render normally.

3b. If the href references to an image, this should be shown in an <img> tag
within the previously created containing div.

I dont know how practical or reasonable that is, though. I would assume that
it'd be possible to use frames on a "lower level" such as this... as the
behavior of these frames will be known by the development team, and AFAIK not an
issue with accessibility.

Comment 20

[Nicklas Bexelius]

Actually it would be extremely nice if there was a Closebutton in every tab,
instead of having to move your mouse to the right corner which, since most
people use mousescroll, is annoying. There are also more positive things with
having a Closebutton in each tab, for example, you may want to close alot of
tabs in one instance. Without having a Closebutton in each tab you would have to
first select the tab, then move your mouse to the right side of the windows and
close, which is quite annoying, especially for me working with many sites on the
same time.

Comment 21

[Felix Miata]

That's bug 108938 (wontfix).

Comment 22

[Nicklas Bexelius]

(In reply to comment #21)
> That's bug 108938 (wontfix).

Why not let people decide for themselves whether this is a good or bad feature,
I think there are alot of people out there who wants this, and if it's a setting
you could always deactivate it if you don't like it?

Comment 23

[Ben Basson]

Because there's an extension that already offers that functionality. It's in TBE
and also there's a standalone extension for that single purpose only.

Comment 24

[Nicklas Bexelius]

(In reply to comment #21)
> That's bug 108938 (wontfix).

Why not let people decide for themselves whether this is a good or bad feature,
I think there are alot of people out there who wants this, and if it's a setting
you could always deactivate it if you don't like it?(In reply to comment #23)
> Because there's an extension that already offers that functionality. It's in TBE
> and also there's a standalone extension for that single purpose only.

The advantages of having the function in the core is, possible speed
advantage/better integration?, no risk of extention colliding with another
extension and you wouldn't have to worry about extension not working with new
builds/slow updating.

Comment 25

[Ben Basson]

1) Stop spamming this bug, go file a new one or post in the "WONTFIX" bug, this
has nothing to do with what you want.

2) It would _never_ be implemented as a "core" feature, simply because the
entire user interface is designed in JavaScript, XUL etc, so your speed
arguement is entirely void. It can be achieved with a small piece of CSS placed
in your userChrome.css file, or by installing one of the two mentioned extensions.

Comment 26

[Andrew Benton]

Sorry to spam this bug some more, but that idea of using CSS in userChrome.css
to put a closebox in tabs sounds interesting. Do you know the code that will do
this?

Comment 27

[Ben Basson]

Seems I was wrong about userChrome.css, but there's an extension which does more
or less what you want here:
http://downloads.us-east3.mozdev.org/clav/tabx/tabx.xpi
It could be better, but it has the functionality you desire.

Comment 28

[Grey Nicholson (they/them)]

Just a note - some people on netscape.public.mozilla.wishlist are asking for
this to be "fixed", i.e. it's currently broken. I suggest upgrading severity to
minor.

Comment 29

[Mike Connor [:mconnor]]

severity != priority, so that's invalid.  Just because someone thinks there is
such a function doesn't mean its broken.

Comment 30

[Grey Nicholson (they/them)]

(In reply to comment #29)
> severity != priority, so that's invalid.  Just because someone thinks there is
> such a function doesn't mean its broken.

It does mean that advertising Firefox as a "tabbed browser" might be
misleading... but that's a different issue.

Comment 31

[Mike Connor [:mconnor]]

why? it is a tabbed browser, just because it doesn't have as much control as it 
might have doesn't mean its not a tabbed browser.

Comment 32

[Nick_Jenkins]

I too wanted a UI more like CrazyBrowser's single-window tabbed browsing. 

With a bit of crude hacking on the JS files, this can be partially achieved, as
detailed below.

Two comments though:
* This isn't and wasn't intended to be an elegant or fast C++ solution, just a
quick-and-dirty JS bandaid until there is some actual code for the C++ solution.
* It doesn't fix bug 103843 or bug 105547 (i.e. JavaScript and target windows
still open in new windows). I'm not sure how to fix these, or even if they can
readily be fixed with JS.


========================================================

* Do not update the main window's title with the current tab's page title -
doesn't makes much sense to do this in a single window mode.

need to extract toolkit.jar then edit
chrome\toolkit\content\global\bindings\tabbrowser.xml:

      <method name="updateTitlebar">
        <body>
          <![CDATA[
+           return;
            var newTitle = "";
            var docTitle;
            if (this.docShell.contentViewer)
              docTitle = this.contentTitle;


[Note - works most of the time, but very occasionally the titlebar gets updated
somehow, so must have another code path somewhere that allows this ]

========================================================

* "Open in new window" should open in tabs, not in a new window
[Need to unzip browser.jar in the "chrome" directory, and edit
"browser\content\browser\contentAreaUtils.js" like so:]

function openNewWindowWith(href, linkNode, securityCheck) 
{
+  try {
+    openNewTabWith(href, linkNode, null, securityCheck);
+    return;
+  }
+  catch(ex) {
+  }

  if (securityCheck)
    urlSecurityCheck(href, document);


[More complete version would check a pref, like so]
+  // should we open it in a new tab instead?
+  var loadInNewWindow = false;
+  try {
+    loadInNewWindow = prefSvc.getBoolPref("browser.singleWindowMode");
+    if (loadInNewWindow) {
+       openNewTabWith(href, linkNode, null, securityCheck);
+       return;
+    }
+  }
+  catch(ex) {
+  }


Effect - the "open in new window" right-click menu now happen in new tabs, but
ctrl-N and the file->new window still give new windows

========================================================

* CTRL-N should open a new tab, not a new window, as should File->New Window 

edit chrome\browser\content\browser\browser.xul from browser.jar :

    <key id="key_newNavigator"
         key="&newNavigatorCmd.key;"
-         command="cmd_newNavigator"
+         command="cmd_newNavigatorTab"
         modifiers="accel"/>
    <key id="key_newNavigatorTab" key="&tabCmd.commandkey;" modifiers="accel"
command="cmd_newNavigatorTab"/>

... and....

                <menuitem label="&newNavigatorCmd.label;"
                          accesskey="&newNavigatorCmd.accesskey;"
                          key="key_newNavigator"
-                          command="cmd_newNavigator"/>
+                          command="cmd_newNavigatorTab"/>
                <menuitem command="cmd_newNavigatorTab" key="key_newNavigatorTab"
                          label="&tabCmd.label;" accesskey="&tabCmd.accesskey;"/>

[DONE - still have unneeded "New window" elements from the UI that could/should
be removed, e.g. from the File menu]

========================================================

* Closing last tab does NOT close the window, but instead adds a new one on
"about:blank"
- with a single window mode, want the main window to stick around, and want a
way of closing that main window that is NOT the same as the way of closing a
single tab.

from browser.jar, edit chrome\browser\content\browser\browser.js  ~line 798:

function BrowserCloseTabOrWindow()
{
  if (gBrowser.localName == 'tabbrowser' &&
gBrowser.mTabContainer.childNodes.length > 1) {
    // Just close up a tab.
    gBrowser.removeCurrentTab();
    return;
  }
+  if (gBrowser.localName == 'tabbrowser' &&
gBrowser.mTabContainer.childNodes.length == 1) {
+    // If this is the last tab, open "about:blank" tab, and don't close the window
+    //    gBrowser.addTab('about:blank'); // opens a new tab, closes current
+    //    gBrowser.removeCurrentTab();   // but causes an ugly brief flashing
effect
+    loadURI('about:blank', null);  // still leaves back & forward buttons
active though
+    // UpdateBackForwardButtons(); // doesn't disable forward and back 
+    return;
+  }

  BrowserCloseWindow();
}

[Done]

========================================================

* Want the word "Blank" to show in tab title, instead of "(Untitled)", as per
other tabbed browsers

[need to extract toolkit.jar]
then edit F:\Moz-Firefox-0.8\chrome\toolkit\content\global\bindings\tabbrowser.xml

      <method name="setTabTitle">
        <parameter name="aTab"/>
        <body>
          <![CDATA[
            var browser = this.getBrowserForTab(aTab);
            var crop = "end";
            var titleViaGetter =
browser.contentDocument.__proto__.__lookupGetter__('title').call(browser.contentDocument);
            var title;
            if (titleViaGetter)
              title = titleViaGetter
            else if (browser.currentURI.spec && browser.currentURI.spec !=
"about:blank") {
              title = browser.currentURI.spec;
              crop  = "center";
            }
+            else if (browser.currentURI.spec && browser.currentURI.spec ==
"about:blank")
+              title = "Blank";
            else
              title = this.mStringBundle.getString("tabs.untitled");

            aTab.label = title;
            aTab.setAttribute("crop", crop);
          ]]>
        </body>
      </method>


[DONE]

Comment 33

[Grey Nicholson (they/them)]

I doubt this will block 1.0 - more pressing matters (such as decent Bookmarks
Manager UI) are "OUT for 1.0" (http://www.mozilla.org/projects/firefox/roadmap.html)
It's a shame we can't target this for 1.1 (bug 234461)...

Comment 34

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Well, this problem will be partially alleviated if the Extension Bundles portion
of the new Firefox Installer comes to be. Then the appropriate extensions, such
as Tabbrowser Preferences, Focus Last Tab Selected and/or Undo Close Tab could
be installed upon request, thus providing the functionality needed while the
other issues are worked out.

Comment 35

[Mike Connor [:mconnor]]

Extension Bundles is unlikely to happen with the advent of update.mozilla.org.  
There's also a number of potential security issues with some (i.e. TBE)

Comment 36

[Michael Hendy (Hendikins)]

*** Bug 248180 has been marked as a duplicate of this bug. ***

Comment 37

[Bogdan Stroe]

*** Bug 250653 has been marked as a duplicate of this bug. ***

Comment 38

[Asaf Romano (gone)]

*** Bug 251693 has been marked as a duplicate of this bug. ***

Comment 39

[Norbert]

Links can be forced to be opened in new tab/window by holding down CTRL/SHIFT
while clicking them, or with the "Open Link in new tab" / "Open Link in new
window" items of the context menu of links.

I think it would be consequent to introduce
also a special key and a menu item "Open Link in current tab" to force links to
open in the current tab.

Comment 40

[Mike Connor [:mconnor]]

maybe as an extension.  Keep in mind that the user has no way of knowing where a
link is going to open, so that would be of limited use, unless you indicated new
window links differently, which we don't want to do.

Comment 41

[Norbert]

to Mike Connor:


(In reply to comment #40)
> Keep in mind that the user has no way of knowing where a
> link is going to open

If the user browses through a link list where he already found one link openinge
in a new tab, I knows that the other links of this list in all probability also
open in new windows!

> so that would be of limited use, unless you indicated new
> window links differently, which we don't want to do.

I think you mean the style of the links itself.

But what about any indication in the status-bar? There alraedy the URL of links
is shown on mouse over. What about to also show the target there? Perhaps with a
small icon....

What do you mean?



Further on, introducing a menu item anf key to force opening of links in current
tab would allow to fix bug 36867 without loosing features!

So please re-consider this.

Comment 42

[Mike Connor [:mconnor]]

point 1: that's guessing at best.
point 2: we have enough stuff going on in the status bar.  For those cases where
you really want the current window (not a new tab) its an edge case and more apt
to cause confusion, IMO.
point 3: that's a really obscure bug, not anywhere near worth justifying what
you're asking for.

Maybe as an extension it'd be useful, but anything beyond a pref is really not
going to happen in the core.  I think you'll notice after a while that I won't
get worn down by arguments that I don't find validity in, so please don't repeat
the process you've gone through on other bugs.

Comment 43

[Norbert]

to Mike Connor:

(In reply to comment #40)
> Keep in mind that the user has no way of knowing where a
> link is going to open

That's incorrect. A way to get this info; maybe a bit circumstantial, is to
right-click "Properties": "Will open in:".

> so that would be of limited use, unless you indicated new
> window links differently, which we don't want to do.

So I think this is a bit inconsequent: You also can say: non-new-window links
are not indicated... I think new-window links should not be seen as special links...



(In reply to comment #42)
>I think you'll notice after a while that I won't
>get worn down by arguments that I don't find validity in, so please don't repeat
>the process you've gone through on other bugs.

Do you want to say users should stop to post suggestions here?

Nevertheless, this is my last comment about this issue...

Comment 44

[Hussam Al-Tayeb]

Attachment: example of a window opened by javascript

Not any link should open in a new tab. For example, some little windows
(legitimate popups) opened by Javascipt will not work if they open in a tab.
The attatchemnt labeled "example of a window opened by javascript" is a
screenshot of a popup opened from my email address. This windows will not
function if it is opened in a new tab. 
If "single window" is someday implemented, firefox should intercept links that
open in a new windows and open them in a new tab instead unless they are
popups.

Comment 45

[Mike Connor [:mconnor]]

there's a bug somewhere to ignore new tab/window requests (i.e. middle-click)
for javascript: URLs, since 98% of the time or more, they don't work in the new
tab/window.  I think its assigned to me, too, and I do intend to fix that for 1.0.

Comment 46

[Jesse Ruderman]

*** Bug 255575 has been marked as a duplicate of this bug. ***

Comment 47

[Matt]

TBE's single-window mode is good, but for links launched from flash, java and
firefox itself, it's a bodge. you'll get new windows appearing, before they are
made into tabs.

single-window mode should really be an option integrated into the heart of
firefox. having multiple tabs in multiple windows, is even more confusing than
having just multiple windows (as in IE).

Comment 48

[Justin Kerk]

The fix for bug 172962 takes care of this too, is there any reason for this to
be a separate bug?

Comment 49

[Steffen Wilberg]

This is now covered by bug 172962.
It provides options (in Options-Advanced-Tabbed Browsing) to open links from
external applications in the current or a new tab. It also lets you force links
that open new windows to open in a new tab.

Get a build from here to test it:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/
It's currently Windows-only, but Mac and Linux implementations are on the way in
bug 172962.

Please open new bugs if you find any problems. Component: Tabbed Browser.

*** This bug has been marked as a duplicate of 172962 ***

Comment 50

[Grey Nicholson (they/them)]

Bug 172962 doesn't seem to cover windows opened by JavaScript window.open() -
that's been fixed and thee's still no option to force window.open()ed windows
into tabs.

Bug 172962 is therefore just a dependency of this one, rather than being the
same bug; so I'm reopening this bug. If bug 172962 does cover window.open(),
this bug should be re-duped to that one.

Comment 51

[Asaf Romano (gone)]

You haven't even checked, Greg. It's now an option in the adavanced tab (tabbed
browsing->Force Links...).

*** This bug has been marked as a duplicate of 172962 ***

Comment 52

[Felix Miata]

Asaf, except for drivers, who can do whatever they want, it is not the place of
a resolver to be also a verifier. Please read the bug QA rules.

Comment 53

[Mike Connor [:mconnor]]

it shouldn't have been reopened, so Asaf's action was to restore the correct
resolution, and then verify as if the reporter had not acted incorrectly.

Also, please don't nit on bugzilla etiquette in the bug, its public flaming,
whereas private email is far more conducive to getting an appropriate response.

Comment 54

[Grey Nicholson (they/them)]

(In reply to comment #51)
> You haven't even checked, Greg. It's now an option in the adavanced tab (tabbed
> browsing->Force Links...).
I did check. With that enabled, window.open() links still open in windows, not
tabs, for me anyway.

Steps to reproduce:
1. Enable "Force links that open new windows to open in a new tab"
2. Visit http://radiotimes.com
3. Click the tab "Today's TV"
4. Click any programme's name

Actual results:
Link opens in a new popup window

Expected results:
Link opens in a new tab - no explicit instruction to open a new window was given

Comment 55

[Steffen Wilberg]

> I did check. With that enabled, window.open() links still open in windows, not
> tabs, for me anyway.
That's true. Only target="_blank" is fixed right now. But also note that bug
172962 contains a patch for window.open, which is reviewed, but not checked in yet.
Bug 172962 covers window.open, and has a patch, so this is a dupe of that.

Comment 56

[Dan M]

Greg is correct (as is Steffen, to a lesser extent), javascript:window.open is
not affected by any part of bug 172962 that is currently checked in. Yes, that
bug does contain a reviewed patch which addresses window.open. However that
patch doesn't completely address all of Single Window mode, and I'm not yet
certain that it should be checked in at all. It was premature to close this bug
against that one.

It seems to me we should let this bug lie and open a new, more focused bug
covering the parts of Single Window that aren't addressed by 172962, if any. I'm
not sure exactly how that new bug will read just yet, so let's not open it just
yet, either.

Comment 57

[Grey Nicholson (they/them)]

Given the new pref, browser.link.open_newwindow.restriction, which Jesse
mentions at http://www.squarefree.com/burningedge/archives/000590.html , I now
believe this is fixed.

Comment 58

[Bill Mason]

*** Bug 264089 has been marked as a duplicate of this bug. ***

Comment 59

[Jesse Ruderman]

*** Bug 264454 has been marked as a duplicate of this bug. ***

Comment 60

[Uplink]

*** Bug 269711 has been marked as a duplicate of this bug. ***

Comment 61

[Jesse Ruderman]

*** Bug 269960 has been marked as a duplicate of this bug. ***

Comment 62

[Matthias Versen [:Matti]]

*** Bug 279299 has been marked as a duplicate of this bug. ***

Comment 63

[Worcester12345]

(In reply to comment #56)
> Greg is correct (as is Steffen, to a lesser extent), javascript:window.open is
> not affected by any part of bug 172962 that is currently checked in. Yes, that
> bug does contain a reviewed patch which addresses window.open. However that
> patch doesn't completely address all of Single Window mode, and I'm not yet
> certain that it should be checked in at all. It was premature to close this bug
> against that one.
> 
> It seems to me we should let this bug lie and open a new, more focused bug
> covering the parts of Single Window that aren't addressed by 172962, if any. I'm
> not sure exactly how that new bug will read just yet, so let's not open it just
> yet, either.

Was this ever done? I saw some recent activity similar to this. Just wanted to make sure, as SingleWindow extension is getting pretty old.