Last Comment Bug 103452 - javascript window.close should close tab, not complete browser window
: javascript window.close should close tab, not complete browser window
Status: VERIFIED FIXED
[ADT2 rtm][verified on trunk]
: dataloss
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: P2 critical with 22 votes (vote)
: mozilla1.0.1
Assigned To: jag (Peter Annema)
: sairuh (rarely reading bugmail)
Mentors:
http://www.devilnews.info/mozilla/ind...
: 104711 104887 104888 108793 109745 111185 111851 118342 119844 120077 122946 123035 125126 127388 127838 129665 129856 131411 131570 132766 133868 134748 135302 137166 139278 139908 140386 141328 142947 144738 144906 147762 147791 148283 149105 149824 150197 150199 151490 151697 152041 152330 152384 154993 155278 155795 156049 156597 157720 158073 160114 161241 163227 163809 168259 170487 172347 (view as bug list)
Depends on:
Blocks: 32571 useragent 128632 143047
  Show dependency treegraph
 
Reported: 2001-10-06 03:21 PDT by Lars Linek
Modified: 2014-04-26 03:20 PDT (History)
105 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch extracted from bug 113798 (2.28 KB, patch)
2002-03-23 12:22 PST, Ere Maijala (slow)
no flags Details | Diff | Splinter Review
Patch extracted from newest patch of bug 113798 (2.19 KB, patch)
2002-03-24 11:30 PST, Ere Maijala (slow)
no flags Details | Diff | Splinter Review
Fire a DOMWindowClose event when window.close() is called (1.80 KB, patch)
2002-05-31 18:41 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Splinter Review
chrome part of patch (616 bytes, patch)
2002-06-02 21:18 PDT, Blake Ross
no flags Details | Diff | Splinter Review
On window.close(), only close the tab, not the whole window (1.57 KB, patch)
2002-06-04 16:46 PDT, jag (Peter Annema)
no flags Details | Diff | Splinter Review
On window.close(), only close the tab, not the whole window (2.73 KB, patch)
2002-06-04 16:51 PDT, jag (Peter Annema)
bryner: review+
hewitt: superreview+
Details | Diff | Splinter Review
On window.close(), only close the tab, not the whole window (2.66 KB, patch)
2002-06-04 17:18 PDT, jag (Peter Annema)
jag-mozilla: review+
jag-mozilla: superreview+
scc: approval+
Details | Diff | Splinter Review

Description Lars Linek 2001-10-06 03:21:04 PDT
i think javascript:self.close() should just close the current tab, when
using them, and not the whole browser window.

see the testcase url for a testcase
Comment 1 Boris Zbarsky [:bz] 2001-10-06 08:50:43 PDT
Confirming.  This could make tabs really annoying.  :)
Comment 2 Alex Vincent [:WeirdAl] 2001-10-12 18:58:40 PDT
New error on console after the window closes:

Error: _content is not defined
Source File: chrome://navigator/content/navigator.js
Line: 948

What would really help is seeing an object model of the new tab browser feature.
Comment 3 Boris Zbarsky [:bz] 2001-10-14 11:44:07 PDT
*** Bug 104711 has been marked as a duplicate of this bug. ***
Comment 4 Olav Vitters 2001-10-15 12:40:29 PDT
*** Bug 104887 has been marked as a duplicate of this bug. ***
Comment 5 Olav Vitters 2001-10-15 12:41:10 PDT
*** Bug 104888 has been marked as a duplicate of this bug. ***
Comment 6 Boris Zbarsky [:bz] 2001-11-06 20:57:44 PST
*** Bug 108793 has been marked as a duplicate of this bug. ***
Comment 7 Lars Linek 2001-11-12 08:58:24 PST
*** Bug 109745 has been marked as a duplicate of this bug. ***
Comment 8 R.K.Aa. 2001-11-21 06:30:18 PST
*** Bug 111185 has been marked as a duplicate of this bug. ***
Comment 9 Niklas Mehner 2001-11-25 10:06:03 PST
*** Bug 111851 has been marked as a duplicate of this bug. ***
Comment 10 Jonas Jørgensen 2001-12-02 13:17:49 PST
This bug can cause a lot of dataloss. Adding keyword, changing prority to
critical and nominating for 0.9.9. (Also changing platform to All - please
change it back if I'm wrong.)
Comment 11 Olav Vitters 2002-01-05 07:07:51 PST
*** Bug 118342 has been marked as a duplicate of this bug. ***
Comment 12 Olav Vitters 2002-01-13 23:05:35 PST
*** Bug 119844 has been marked as a duplicate of this bug. ***
Comment 13 Alfonso Martinez 2002-01-15 08:10:51 PST
*** Bug 120077 has been marked as a duplicate of this bug. ***
Comment 14 David Hyatt 2002-01-21 13:52:37 PST
Reassigning to new component owner.
Comment 15 MatthiasMann 2002-01-23 11:17:11 PST
voted and adding myself to cc ...
Comment 16 Peter Trudelle 2002-01-26 15:39:35 PST
How common is the use of this function?  clearing target for re-triage by new
owner.  
Comment 17 David Illsley 2002-01-27 04:39:52 PST
This function is actually quite common. It is very noticable if you use Right
Click --> open in new tab often because you then quite often get windows which
the author intended to be new and chromeless and therefore entitled to close in
a tab. I have noticed this in my on-line banking service and sevaral other places.
Comment 18 jag (Peter Annema) 2002-01-28 07:35:09 PST
I guess it's common enough that I can spend some time on this.

jst, is there an easy way for me to hook into window.close() and have it execute
some XUL js which can tell it to not proceed?
Comment 19 Johnny Stenback (:jst, jst@mozilla.com) 2002-01-28 13:53:17 PST
Look at GlobalWindowImpl::Close().
Comment 20 R.K.Aa. 2002-02-01 01:36:46 PST
*** Bug 122946 has been marked as a duplicate of this bug. ***
Comment 21 Quinn Yost (mythdraug) 2002-02-01 12:50:27 PST
*** Bug 123035 has been marked as a duplicate of this bug. ***
Comment 22 jag (Peter Annema) 2002-02-07 15:38:55 PST
-> 1.0
Comment 23 Peter Trudelle 2002-02-11 11:34:49 PST
nsbeta1+ per nav triage team
Comment 24 Olli Pettay [:smaug] 2002-02-12 08:20:54 PST
My latest patch in http://bugzilla.mozilla.org/show_bug.cgi?id=113798
includes a hack for this too. But it is just a hack.
Comment 25 Matthias Versen [:Matti] 2002-02-12 16:25:27 PST
*** Bug 125126 has been marked as a duplicate of this bug. ***
Comment 26 Alfonso Martinez 2002-02-23 05:58:09 PST
*** Bug 127388 has been marked as a duplicate of this bug. ***
Comment 27 Alfonso Martinez 2002-02-26 06:27:20 PST
*** Bug 127838 has been marked as a duplicate of this bug. ***
Comment 28 Dimitrios 2002-03-08 07:27:13 PST
*** Bug 129665 has been marked as a duplicate of this bug. ***
Comment 29 Matthias Versen [:Matti] 2002-03-09 09:12:31 PST
*** Bug 129856 has been marked as a duplicate of this bug. ***
Comment 30 Peter Trudelle 2002-03-14 18:05:54 PST
ADT2 per ADT triage team.
Comment 31 Malx 2002-03-16 06:47:29 PST
*** Bug 131411 has been marked as a duplicate of this bug. ***
Comment 32 Chris Lyon 2002-03-17 09:45:02 PST
*** Bug 131570 has been marked as a duplicate of this bug. ***
Comment 33 Ere Maijala (slow) 2002-03-17 13:07:37 PST
Uh oh, got bitten by this...
Comment 34 Markus Långström 2002-03-22 05:43:55 PST
*** Bug 132766 has been marked as a duplicate of this bug. ***
Comment 35 Ere Maijala (slow) 2002-03-23 12:22:50 PST
Created attachment 75781 [details] [diff] [review]
Patch extracted from bug 113798

Author: smaug@jippii.fi

Extracted patch from a set of tabbrowser patches. Categorized as hack by
author.
Comment 36 Ere Maijala (slow) 2002-03-24 11:06:15 PST
I just found out that I took the parts from an old patch. I'll try to make a new
one.
Comment 37 Ere Maijala (slow) 2002-03-24 11:30:58 PST
Created attachment 75856 [details] [diff] [review]
Patch extracted from newest patch of bug 113798
Comment 38 jag (Peter Annema) 2002-03-26 15:21:19 PST
We shouldn't accept this patch. We could potentially be overriding a user
installed close function, something we don't want to do.
Comment 39 Peter Trudelle 2002-03-27 01:09:30 PST
Alright, I'll bite: what's a 'user installed close function'?
Comment 40 Olli Pettay [:smaug] 2002-03-27 05:41:29 PST
jag wrote:
>We shouldn't accept this patch. We could potentially be overriding a user
>installed close function, something we don't want to do.

Yep, that was the reason for calling the patch a hack.
But if we change the close function at the beginning
of the loading then user could override it later?
Comment 41 Boris Zbarsky [:bz] 2002-03-27 07:22:24 PST
Trudelle:

The patch basically does the following:

function myfunc () {
  // do something cool
}
window.close = myfunc;

This means that calling window.close() or close() now calls myfunc instead of 
the default built-in close-window function.

The point is that the page author can do something like:

function close () {
 // this is my close function
}

This sets window.close and this will either override our function definition or 
be overriden by our definition depending on which happens first.  The former 
outcome may be OK, the latter is unacceptable.
Comment 42 Ian Thomas ('thelem') 2002-03-27 07:29:15 PST
Can't we just set window.close to call the same code as CTRL+W does at the moment?
Comment 43 Manko 2002-03-27 07:46:29 PST
I think, the problem is more global. Window had been opened not via JavaScript,
must not have been closed by scripting without confirmation. Tab interface
intensifies situation, but root of all evils is located not in tabs.

NS4 and MSIE never close non-scripted windows without user's consent, and I
would expect same behavior of Mozilla.
Comment 44 Urban A. Haas 2002-03-27 19:47:47 PST
Yes, consent is nice, but in my case, I'm looking at something in one tab, and I
open a tab to my banking application. I expect the close function to close the
tab, not the window, because I am using tabbed browsing.

If this is ambigious, like you THINK that window.close SHOULD close the window,
with all tabs in it, then there needs to be a pref to make the rest of us happy
that says, window.close closes the tab and not the window.

When going to tabbed browsing, NS4 and IE are not fair comparisons, since they
are not doing tabbed browsing. But I would argue that anything, even beyond
window.close, but any window action, should apply only to the tab and not the
window, meaning all tabs. Tabs should be considered their own window in one
windows,mac,Unix/Linix icon-saving friendly interface.

It's a larger can of worms to open, but one that should definitely be
considered. Maybe that's beyond the scope of THIS bug, which has caused data
loss for me in other tabs when window.close was called. But it still needs to be
thought out. Of course, someone wanting to pop-up a window probably doesn't want
to land in a tab, because they may be sizing that window. See where this can go?
Comment 45 Vadim Berezniker 2002-03-27 21:27:51 PST
*** Bug 133868 has been marked as a duplicate of this bug. ***
Comment 46 Manko 2002-03-28 01:20:10 PST
OK, I think, this bug should be splitted to 2 separate threads:

1. javascript window.close should close tab, not complete browser window -
according description of #103452

2. javascript window.close closes non-scripted windows/tabs without confirmation
- this sould be separate bug thread, I have opened #133904 for this issue.

See http://bugzilla.mozilla.org/show_bug.cgi?id=133904
Comment 47 Vadim Berezniker 2002-04-01 16:26:29 PST
*** Bug 134748 has been marked as a duplicate of this bug. ***
Comment 48 Boris Zbarsky [:bz] 2002-04-03 16:52:02 PST
*** Bug 135302 has been marked as a duplicate of this bug. ***
Comment 49 Phil Schwartau 2002-04-12 13:10:34 PDT
*** Bug 137166 has been marked as a duplicate of this bug. ***
Comment 50 Ryan Egesdahl 2002-04-15 22:06:13 PDT
Hmmm, looks like quite a conundrum has arisen over this...

Consider: window.close() should not close a non-scripted window. I know this 
has been moved to another bug, but part of the problem might lie in how 
window.close() is treated.

Consider: window.close() should close the current tab in tab-mode and the 
current window in window-mode. This automatically suggests two distinct 
behaviors for the window.close() function. The question is, do we incorporate 
both functions statically, or can we reassign the function name itself to a 
different piece of code for each window and/or tab?

It might be worthwhile to consider having the window.close() function be a 
function pointer, for the purposes of abstraction. Thus, in window-mode, each 
window has its own window.close() function pointer (if scripted) which might 
point to one static function, then in tab-mode to have the window.close() 
function point to another static function so tabs are treated differently. 
Then, for both window- and tab-mode another function could be devised which 
asks the user's permission before closing the window. I'm not sure about any 
security risks concerning this, as I haven't looked at the code, but might it 
be possible to allow the pointer reassignment to be done only by the parent 
thread, and to declare any overt reassignments of window.close() within script 
to be illegal?

(I'm racking up quite a bill for talk today :-)
Comment 51 Boris Zbarsky [:bz] 2002-04-15 22:22:12 PDT
> and to declare any overt reassignments of window.close() within script 
> to be illegal?

This would likely break webpages that don't ever use window.close() but want to
define a variable or function called "close".
Comment 52 Vadim Berezniker 2002-04-22 13:39:01 PDT
*** Bug 139278 has been marked as a duplicate of this bug. ***
Comment 53 Ryan Egesdahl 2002-04-24 00:09:03 PDT
Hm. I suppose you are right at that.
I haven't even looked at the code. In fact, I haven't looked at any code in a 
good long while, being more concerned with system design lately, but I did do a 
little research on the problem.

It might be possible to have window.close() follow the current thread upwards 
to the parent. The parent thread could then determine the correct course of 
action for the window.close() code. I'm not sure how this could be implemented, 
since I haven't even looked at what is really going on, but it's an idea at 
least.

::Ah! I love the smell of microchips in the morning! Wait a minute...::
Comment 54 Jesse Ruderman 2002-04-24 21:04:08 PDT
*** Bug 139908 has been marked as a duplicate of this bug. ***
Comment 55 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-26 12:53:17 PDT
*** Bug 140386 has been marked as a duplicate of this bug. ***
Comment 56 Boris Zbarsky [:bz] 2002-04-30 15:13:53 PDT
*** Bug 141328 has been marked as a duplicate of this bug. ***
Comment 57 Marcus Pallinger 2002-05-02 18:44:28 PDT
As a work around to the whole window closing, the following pref might be semi
useful. Of course with it, no windows will close with Window.close...

user_pref("capability.policy.default.Window.close", "noAccess");

No, It's nto a sulution, but may atleast help some of you.
Comment 58 mental 2002-05-07 21:43:53 PDT
*** Bug 142947 has been marked as a duplicate of this bug. ***
Comment 59 gabriel 2002-05-08 07:49:18 PDT
This is in response to comment 50. It seems clear enough to me. Isn't window
mode the same as tab mode, but with only one tab ? If that's the case then just
close the current tab, and if there are no more tabs in the window, close the
window. That seems entirely consistent to me.
Comment 60 Pavol Vaskovic 2002-05-11 01:07:26 PDT
Exactly as stated in previous comment. We have implemented "close document"
gesture in Mozgest this way. Here is the code we use:

function closeDoc(){
  if (getBrowser().mTabContainer.childNodes.length > 1)
    getBrowser().removeCurrentTab();
  else window.setTimeout("window.close()", 10); 
}

Hope this helps.
Comment 61 Ariel Shkedi 2002-05-14 22:25:18 PDT
Until this bug 103452 is fixed, bug 32571 can not be considered completely
fixed, since window.close still closes windows it doesn't own - in other tabs.
Comment 62 Christopher Aillon (sabbatical, not receiving bugmail) 2002-05-15 05:43:27 PDT
*** Bug 144738 has been marked as a duplicate of this bug. ***
Comment 63 Matthias Versen [:Matti] 2002-05-15 18:12:56 PDT
*** Bug 144906 has been marked as a duplicate of this bug. ***
Comment 64 Christian Eyrich 2002-05-24 05:01:19 PDT
voting for the bug and for solutions as suggested in #c59 anc #c60.
Comment 65 R.K.Aa. 2002-05-28 19:45:03 PDT
*** Bug 147762 has been marked as a duplicate of this bug. ***
Comment 66 Ariel Shkedi 2002-05-28 22:43:56 PDT
I _very_ strongly disagree that this bug can wait till version 1.0.1 - it is a
_critical_ security fix!!

Not to mention it's an extremely simple fix!
Comment 67 Boris Zbarsky [:bz] 2002-05-28 22:46:07 PDT
It's simple?  Did I miss something?
Comment 68 Adam Hauner 2002-05-28 23:01:02 PDT
Ariel Shkedi: This bug is still targeted to M1, but non-existing patch couldn't
be included to soon released M1. I suppose, that mozilla1.0 and mozilla0.9.9
keywords are redundant for this bug. BTW Jag has about 249 bugs and this bug is
one of the five with highest priority.
Comment 69 Peter Trudelle 2002-05-29 02:25:11 PDT
But it seems difficult/risky.  Unless someone has a flash of insight, this one
is probably not going to be fixed for MachV/1.0.1
Comment 70 Manko 2002-05-29 08:07:37 PDT
Maybe, just deny window.close() for non-chrome scripts as a palliative?
Comment 71 Malcolm Scott 2002-05-29 10:29:23 PDT
Or deny window.close for any window that wasn't opened in javascript? (If that's
possible...)

This would be an ideal temporary measure since window.close is usually used in a
'Close' button on a javascript-generated popup window. Heck, you could get the
same effect by only allowing window.close when there's a URL bar visible! (since
most popup windows hide the URL bar).

Surely it's possible to implement some sort of temporary "fudge" that improves
things in most cases, until the bug is fixed for real. I admit the URL bar fudge
would be technically horrendous, but at least it would appear to work 95% of the
time as far as end-users are concerned.
Comment 72 Urban A. Haas 2002-05-29 10:50:08 PDT
It would be great if window.close closed a tab instead of a window. And closing 
of a tab, if it were the only tab, would close the window. For me, I have a 
logout button on a home banking site. Logout calls window.close; the problem is, 
it's usually in another tab, not it's own window.
Comment 73 Vincent Lefevre 2002-05-29 12:31:19 PDT
It has been said that window.close should close the tab instead of the window;
it seems that this is because one could lose data in other tabs. But then, to be
consistent, I would say: it should only close the page(*) or perhaps a group of
pages belonging to the same site, because one could lose data that were in the
same tab, accessible with the Back button.

(*) a bit like clicking on Back (but one can't forward afterwards), and the tab
or window is closed if it was the first page.
Comment 74 Phil Schwartau 2002-05-29 13:59:32 PDT
*** Bug 147791 has been marked as a duplicate of this bug. ***
Comment 75 Ariel Shkedi 2002-05-29 20:13:23 PDT
Vincent Lefevre: that's not really a problem (that closing the tab/window looses
data from 'back' button). Because if bug 32571 were fixed only windows that were
opened via javascript (or chrome) will close automatically. Other windows will
give you a dialog and ask you if you want them to close.
Comment 76 Judson Valeski 2002-05-30 08:14:33 PDT
Assuming resolution on approach, this seems like something we should go after in
1.0.1, any chance of an updated patch? minusing for now, please re-nominate if a
patch appears with consensus.
Comment 77 John Morrison 2002-05-30 18:20:34 PDT
*** Bug 148283 has been marked as a duplicate of this bug. ***
Comment 78 Johnny Stenback (:jst, jst@mozilla.com) 2002-05-31 18:41:13 PDT
Created attachment 85860 [details] [diff] [review]
Fire a DOMWindowClose event when window.close() is called

This is part of one way of fixing this bug. This makes the implementation of
window.close() fire a DOMWindowClose event that event listeners in chrome code
can capture and if a listener prevents the default action of this event the
window won't be closed. The remaining part is to add the listener for this
event in the tab UI code...
Comment 79 Stuart Lamble 2002-05-31 23:24:48 PDT
I'm a little bit worried about jst's patch. I don't know a great deal about the
mozilla source, but I'd like to know: if the user is looking at tab 2 (for the
sake of argument), and tab 4 fires off a window.close(), could the patch result
in tab 2 being closed, instead of tab 4?

I could be wrong. I hope I'm wrong. But closing the wrong tab is only marginally
better than closing the whole window. Yes, I'm being obvious... I'll shut up
now. :-)
Comment 80 Johnny Stenback (:jst, jst@mozilla.com) 2002-05-31 23:41:17 PDT
The window in which the event is fired is the one that will be closed,
independent of if the tab is the one that's currently displayed or not. And yes,
if tab 2 has permissions (and somehow got a reference to the other tab, which I
believe is impossible) to call tab 4's window.dispatchEvent() tab 2 could cause
tab 4 to close, but that's no different than tab 2 calling tab 4's
window.close() directly. IOW this patch does *not* let malicous scripts do
anything they can't already do.
Comment 81 Blake Ross 2002-06-02 21:18:42 PDT
Created attachment 86009 [details] [diff] [review]
chrome part of patch
Comment 82 Boris Zbarsky [:bz] 2002-06-03 08:06:38 PDT
Um... that seems to have the exact problem described in comment 79.  That is, 
the tab that is closed is always the "current" tab, regardless of which tab 
actually fired the event.  We want to be checking the event target against the 
toplevel windows in all the tabs and closing the tab whose window matches the 
event target, no?
Comment 83 Johnny Stenback (:jst, jst@mozilla.com) 2002-06-03 09:30:00 PDT
Yup, that's what we'd need to do...
Comment 84 Sander 2002-06-04 15:08:21 PDT
*** Bug 149105 has been marked as a duplicate of this bug. ***
Comment 85 jag (Peter Annema) 2002-06-04 16:46:54 PDT
Created attachment 86318 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

So it looks like the value that DispatchEvent returns is the inverse of what it
should be, I'll talk to hewitt about this and file a new bug if necessary. In
the mean time I'm just inverting the check in jst's patch, and adding the
tabbrowser code to make this all work.
Comment 86 jag (Peter Annema) 2002-06-04 16:51:24 PDT
Created attachment 86322 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

Attached the wrong file
Comment 87 jag (Peter Annema) 2002-06-04 16:54:02 PDT
Ignore that dump :-)
Comment 88 Johnny Stenback (:jst, jst@mozilla.com) 2002-06-04 16:56:05 PDT
Comment on attachment 86322 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

sr=jst for the tabbrowser.xml changes with the debug dump() removed.
Comment 89 jag (Peter Annema) 2002-06-04 17:01:21 PDT
sr=jag on the changes to nsGlobalWindow.cpp.
Comment 90 Brian Ryner (not reading) 2002-06-04 17:08:45 PDT
Comment on attachment 86322 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

r=bryner
Comment 91 Joe Hewitt (gone) 2002-06-04 17:09:44 PDT
Comment on attachment 86322 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

sr=hewitt, but change noDefault to noPreventDefault, as we discussed
Comment 92 jag (Peter Annema) 2002-06-04 17:18:37 PDT
Created attachment 86328 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

It turns out the value returned is what the DOM says it should be, false if
preventDefault() was called, true if not. So it's really |executeDefault|. Imho
a renaming of those parameter names would be wise. Different bug though, new
patch with the var name changed for this patch and the dump removed.
Comment 93 jag (Peter Annema) 2002-06-04 17:21:00 PDT
Comment on attachment 86328 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

Carrying over r=hewitt, sr=jag, sr=jst
Comment 94 jag (Peter Annema) 2002-06-04 17:40:34 PDT
-> 1.0.1 (won't make 1.0), adt1.0.1 (want this for NS RTM), mozilla1.0.1 (want 
this in that release), fixed (trunk).
Comment 95 Ariel Shkedi 2002-06-04 19:25:04 PDT
I (and we) greatly appreciate your fixing this bug! But are you sure this can't
make it into 1.0?

The entire world will be looking at the release - and tabs is going to be at the
top of reviewers lists because it's a feature IE doesn't have.

A bug like this - which reviewers _are_ going to notice is going to be
embarrassing for mozilla. Especially because of bug 32571 it's going to look
like the browser just crashed! (And bug 32571 just noted a target of
mozilla1.2alpha!)

You have working code - can't you ask for an exception (if necessary) and
squeeze this in? I think this bug deserves an exception if one is needed.
Comment 96 jag (Peter Annema) 2002-06-04 20:28:59 PDT
Only bugs that will make this universe cease to exist would be able to delay
shipping of Mozilla 1.0 at this point, and even then it's a big if.
Comment 97 Jaime Rodriguez, Jr. 2002-06-05 21:14:18 PDT
sairuh - can you pls verify this one on the trunk, and check for any
regresssions? thanks!
Comment 98 Michael Hendy (Hendikins) 2002-06-06 20:48:24 PDT
*** Bug 149824 has been marked as a duplicate of this bug. ***
Comment 99 Christian Eyrich 2002-06-07 09:24:49 PDT
If I call opener.close() from a window opened by code in a tab, the tabbed
window will become the top window not the one opener.close() called from.
New bug or result of this and so stay here?
Comment 100 jag (Peter Annema) 2002-06-07 13:45:26 PDT
If it is a bug (could one see it as a feature?), I would say it's a bug that's
exposed because we got this working. Could you file a new bug on it for further
investigation?
Comment 101 Jim Balter 2002-06-07 18:02:30 PDT
I note that no one ever responded to comment #42 which, as an
outsider, and as a (new) user, I find odd, since ctrl+W, despite the
mnemonic, executes the operation I expect and want to execute -- close
*tab* (naturally, a tabless window disappears), and the fact that this
bug exists indicates, I believe, improper (or absent) modelling of the
UI.  From a user perspective, tabs almost replace browser windows.  I
have already lost large amounts of data through habitually typing
alt+F4 to close a "window" which was actually a tab -- I'm trying to
break that habit, but it deserved at least a relnote.  Another very
serious consequence of this failure in UI modelling is that there is
no apparent way to open a bookmark into a tab -- this greatly reduces
the usefulness of tabs.  And, there are missing features that would
have been obviously desirable given a fully modelled UI -- such as being
able to drag and drop a tab from one window to another.
Comment 102 Christopher Aillon (sabbatical, not receiving bugmail) 2002-06-07 18:23:51 PDT
I'll respond then.  the code that CTRL+W does is to look at the tab that is
currently open and then close that.  It would suck if you loaded a page, it has
some JS that does stuff for a few minutes, you switch to a different tab, and
then we call the code that CTRL+W does which closes the currently active tab
(different than the tab that called window.close since you have switched tabs).

This bug is fixed.  Please take any other issues/requests to different/new bugs.
 Thanks
Comment 103 sairuh (rarely reading bugmail) 2002-06-07 19:11:26 PDT
vrfy'd fixed using 2002.06.07.08-trunk bits on linux rh7.2.
Comment 104 Daniel Veditz [:dveditz] 2002-06-07 19:38:24 PDT
Jim Balter: What was your point in comment 42? that's more or less what the
patch does. It requires cooperation between the window container and the tab
control since unlike keystroke events there's no way for the tab control to
intercept the user directly tickling the window object (although cf. the clever
initial attempt to override the .close() method on the prototype, ultimately
prevented by a recent security patch).

As to bookmarks, menu items have a very simple UI -- you click them or not. If
you want to use the bookmark menu you will have to open a tab first. If you have
items in your personal toolbar you can drag them to an empty bit of the tab area
and it will open a new tab. If you use the bookmark sidebar you can drag links
to an empty bit of the tab area to open a new tab.

It would be consistant if you could drag the icon on the tab, but for the open
tab you can drag the same icon up in the URL bar to the tab area of another
window to open it in a new tab. If you drag it to the content area itself it
will open in the existing tab. If you think this is something you want to do a
lot you probably want to uncheck the "Hide tab bar when only one tab is open" pref.
Comment 105 Matthias Versen [:Matti] 2002-06-08 07:34:20 PDT
*** Bug 150199 has been marked as a duplicate of this bug. ***
Comment 106 Matthias Versen [:Matti] 2002-06-08 07:35:15 PDT
*** Bug 150197 has been marked as a duplicate of this bug. ***
Comment 107 Adrian Ulrich 2002-06-12 01:34:29 PDT
*** Bug 151123 has been marked as a duplicate of this bug. ***
Comment 108 Scott Collins 2002-06-12 17:36:19 PDT
Comment on attachment 86328 [details] [diff] [review]
On window.close(), only close the tab, not the whole window

a=scc (on behalf of drivers) for checkin to the mozilla1.0 branch.

when you check this into the branch, please change the mozilla1.0.1+ keyword to
fixed1.0.1
Comment 109 jag (Peter Annema) 2002-06-12 22:18:44 PDT
Marking verified per comment 103
Comment 110 gabriel 2002-06-13 04:59:39 PDT
*** Bug 151490 has been marked as a duplicate of this bug. ***
Comment 111 Syd Logan 2002-06-13 07:15:59 PDT
adt1.0.1+ added.
Comment 112 Christopher Aillon (sabbatical, not receiving bugmail) 2002-06-13 19:20:37 PDT
*** Bug 151697 has been marked as a duplicate of this bug. ***
Comment 113 David Illsley 2002-06-15 12:18:21 PDT
*** Bug 152041 has been marked as a duplicate of this bug. ***
Comment 114 Sander 2002-06-17 09:50:18 PDT
*** Bug 152330 has been marked as a duplicate of this bug. ***
Comment 115 Oliver Klee 2002-06-17 13:14:03 PDT
*** Bug 152384 has been marked as a duplicate of this bug. ***
Comment 116 scottputterman 2002-06-17 17:46:55 PDT
Please check this in asap and change the mozilla1.0.1 keyword to fixed1.0.1
Comment 117 sairuh (rarely reading bugmail) 2002-06-27 17:18:01 PDT
verified on the branch using 2002.06.27.0x comm bits (all platforms).
Comment 118 Alfonso Martinez 2002-06-29 10:42:34 PDT
*** Bug 154993 has been marked as a duplicate of this bug. ***
Comment 119 Matthias Versen [:Matti] 2002-07-01 17:48:51 PDT
*** Bug 155278 has been marked as a duplicate of this bug. ***
Comment 120 Adrian Ulrich 2002-07-04 11:19:17 PDT
*** Bug 155795 has been marked as a duplicate of this bug. ***
Comment 121 Sven Krohlas 2002-07-06 14:51:18 PDT
*** Bug 156049 has been marked as a duplicate of this bug. ***
Comment 122 Andrew Schultz 2002-07-09 21:49:46 PDT
*** Bug 156597 has been marked as a duplicate of this bug. ***
Comment 123 Matthias Versen [:Matti] 2002-07-16 09:50:54 PDT
*** Bug 157720 has been marked as a duplicate of this bug. ***
Comment 124 jag (Peter Annema) 2002-07-18 02:49:57 PDT
*** Bug 158073 has been marked as a duplicate of this bug. ***
Comment 125 Phil Schwartau 2002-07-19 09:27:55 PDT
*** Bug 157720 has been marked as a duplicate of this bug. ***
Comment 126 Marcus Campbell 2002-07-30 08:46:08 PDT
*** Bug 160114 has been marked as a duplicate of this bug. ***
Comment 127 Alfonso Martinez 2002-08-06 01:34:55 PDT
*** Bug 161241 has been marked as a duplicate of this bug. ***
Comment 128 Alfonso Martinez 2002-08-17 09:48:25 PDT
*** Bug 163227 has been marked as a duplicate of this bug. ***
Comment 129 Marcus Campbell 2002-08-21 01:06:30 PDT
*** Bug 163809 has been marked as a duplicate of this bug. ***
Comment 130 Matthias Versen [:Matti] 2002-09-12 10:54:54 PDT
*** Bug 168259 has been marked as a duplicate of this bug. ***
Comment 131 Olivier Cahagne 2002-09-24 03:24:11 PDT
*** Bug 170487 has been marked as a duplicate of this bug. ***
Comment 132 WD 2002-10-06 09:22:17 PDT
*** Bug 172347 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.