190515 - window.close() for non-script-owned windows is ignored (should create a dialog or "please close me" page)

Status: NEW

Description

[Jon Earle]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

According to
http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1201822):

"The close method closes only windows opened by JavaScript using the open
method. If you attempt to close any other window, a confirm is generated, which
lets the user choose whether the window closes."

window.close() should work, even if it generates a confirmation message.  There
are extensive documents on the web that describe this action/script to close the
browser window.  Removing this feature will affect many applications and
websites that make use of it.

The following code would create a button that, when clicked, closed the browser
window:

<input type="button" value="Click Here" onclick="this.close()">

Mozilla v1.0 closed the window.  IE presents a dialog and closes the window on
positive confirmation.  Mozilla v1.2.1 does not work at all; no dialog, no action.

Can a patch be added that will restore the close() function with the appropriate
confirmation dialog?

Reproducible: Always

Steps to Reproduce:
See bug details.


Expected Results:  
Close the browser window on receiving positive confirmation from the user.

Comment 1

[Jon Earle]

NOTE: From the sample html code in the original report: this.close() should read
window.close().  I was trying variants (document, self, etc) to see if anything
worked.  Didn't catch the typo until after I posted the bug.

Comment 2

[Matthias Versen [:Matti]]

see bug 183697

Comment 3

[Mitchell Stoltz (not reading bugmail)]

I deliberately did not add a confirmation dialog, because I think they're
annoying and detract from the user experience. In my mind, it would be less
annoying for a web page to simply tell the user "Please close this window now."

Can you point me at some of the "many applications and websites" that need to
close user-opened windows? If there are in fact many of them, and especially if
any of them are "Top 100" sites, I may reconsider.

Comment 4

[Jon Earle]

Top 100 sites?  I can't speak to that - I don't go browsing looking for "top
100" sites.  However, a very brief search on the net for "close a browser
window" will turn up literally _dozens_ of links to pages that describe using
window.close() to close a window.  If it's widely documented, logic would
presume that it's also commonly utilized.

I will admit to a bias in that I'm developing an application that uses this.  It
works in IE, used to work in Mozilla, and now the Mozilla behaviour is broken.

Since the Netscape developer docs say this behaviour should exist, I wouldn't
think one developer's personal annoyances should intrude on adhering to existing
specifications.  Please note, I'm not trying to be rude, rather, I'm trying to
very emphatically point out the fact that this violates agreed-upon
specifications, not to mention, the _expectations_ of users and developers who
have used this capability (for long enough to allow it to become widely documented).

Comment 5

[José Jeria]

Without any confirmation you get the impression that something is broken If you
would click a "close me" button. No dialog, nothing. How good user expierence is
that?
I dont think regular users check the javascript console to see what went wrong. 

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Jose, that's up to the site developer to fix.

Jon, the docs you referenced are out of date and "existing specifications" are
often in the eye of the beholder. However, I will consult with some UI experts
and see what they think; I'm not going to WONTFIX this bug out of hand. I just
want to get some more opinions.

Comment 7

[Jon Earle]

Thanks Mitchell, I'll look forward to your comments.

Jon

Comment 8

[Jesse Ruderman]

I'm against adding this dialog for two reasons:

* We should avoid adding security dialogs to which the most reasonable answer on
a porn site is "yes".  Porn sites are known to spoof browser dialogs, and I
wouldn't be surprised to see one put up this dialog until the user gets used to
clicking "yes", with the intent of later substituting a more dangerous dialog on
a similar-looking page.  (cf bug 68215, which would add an "onbeforeunload"
event to let pages put up "Are you sure you want to leave this page?" dialogs.)

* In every case, using window.close() is slower than closing the window by
clicking the 'X' in the upper-right corner of the screen.

  o "close window" link/button, user wants to close
      2 clicks instead of 1 fast click
  o page calls window.close() onload, user wants to close
      1 click instead of 1 fast click (assuming window is maximized)
  o page calls window.close() onload, user doesn't want to close
      1 click instead of 0 clicks

Comment 9

[David G King]

I generally don't click on the "Close Window" button as I consider it too
"dumbified", however, I did today and it didn't work. I got a JS informational
"error" 'Scripts may not close windows that were not opened by script'. This
kind of makes sense, however, I'd still expect something to happen. Ideally, the
window to close.

I'm adding an example URL for illustration purposes. I got to this URL after
adding myself to the Pfizer mailing list "http://148.168.116.157/formhandlerHEN.asp"

I tried this on Netscape 4.8, and noticed that the button wasn't displayed,
however after a few seconds I got a popup message instead.

Comment 10

[Dan Backes]

Well I think it's obvious that there are two very valid schools of thought on
this, so I suggest a comprimise. Make it so that there is an option to
enable/disable the window.close() function. I mean, I'm no 1337 programmer, but
I can't imagine this being that difficult to do. Sure, you can click the "x"
button, but as it was said, if you click a button that says close window, and
nothing happens, a reasonable person would assume that something is up.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

> I mean, I'm no 1337 programmer, but I can't imagine this being that difficult
to do.

If I had a nickel for every time I've seen that sentence used in a bug, I
wouldn't have to work here. :)

In this case, you're right that it would be easy to add a pref, but I'm trying
very hard to avoid pref-bloat - there are an awful lot of nitpicky things that
we could add prefs for, but that just clutters up the app. It's much better to
choose the right behavior and stick with it.

Comment 12

[Mitchell Stoltz (not reading bugmail)]

OK, I haven't seen any evidence that this is breaking a lot of web apps, do I'm
marking it Wontfix.

Comment 13

[Jon Earle]

I disagree, Mitchell.  The correct behaviour is, IMO, to provide what users and
(web app) developers expect.  The developer docs (which you state are out of
date but are still the referenced docs, AFAICT) claim that the correct behaviour
is to prompt the user for confirmation.

Even in this thread alone, there are 4 (incl me) who think that the option
should exist in some form, and two (incl you) who don't.  There are other
reports on the same bug.  Obviously, this is an issue that needs to be
addressed, not simply ignored.

One's personal preferences should not override the reasonable expectations of
the community.

Comment 14

[John G. Tesmer]

I agree with Jon. This needs to be addressed, as I know that here in IBM where 
we support both IE and Mozilla, it would be nice to have them behave similarly. 
I speak for myself, but I expected this to function as described in the spec, 
and how it has operated in the past (to prompt the user).

If this issue is closed as is, then web apps will have to be coded for IE and 
Mozilla separately.

Also, I have not seen a spec where this behavior has been changed. You're 
correct to point out that the JavaScript language spec is "out of date" for 
1.3, but what about the DOM and it's specification? I see no updated version of 
it in 1.5, or am I looking in the wrong place? I think this is not an argument 
of JavaScript syntax, but rather of the object model and its function, and I 
haven't seen an update to the object model.

Comment 15

[José Jeria]

A confirmation dialog is what every web developer would except in this
situation. This creates confusion, cause all other browsers (event nn4) have
this dialog:
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&frame=right&th=6b322df92a345d99&seekm=%23%23Div5EUDHA.2260%40TK2MSFTNGP12.phx.gbl#link4

Comment 16

[Jesse Ruderman]

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

Comment 17

[Jason Jackson]

I was javascripting, and ran into this "bug", and don't understand the intended
behavior in Mozilla.  

Lets use this page as an example:
http://www.codeave.com/javascript/code.asp?u_log=7014  If you click "View the
Output" (a hyperlink to another page), you can click either of them, and it
closes with window, without a dialog.  But, if instead right-click and use "Open
Link in New Window", it doesn't close the window anymore.  If you go to the url
of the second page directly, it doesn't close either.  Is this intended?

As a note, for the three cases mentioned above, both IE and Opera close the
window in all cases. (Although, IE gives a prompt, Opera does not.)

I can understand deciding on a behavior is difficult, but it has to be decided.
 For my two cents worth, I like Opera's choice in behavior.

Comment 18

[Doron Rosenberg (IBM)]

A dialog would be great, as often for security reasons, enterprise web
applications want to shut down the whole browser when the web application is
"closed".

Comment 19

[Margaret Lum]

I work for a company whose product *requires* the Javascript functionality of
window.close() in order to close the browser window that starts it.

I suggest adding the option in the browser for "allow scripts to close windows",
because the following customer-vendor steps happen:

1. customer complains they can't close window
2. customer stops using Mozilla, when we tell them to use IE instead
3. we blame lack of window.close() functionality on Mozilla, since our product
uses window.close()
4. our product is predominantly for spam-prevention, so mozilla preempts a
portion of our functionality in their effort to prevent spamming
5. since we're a mostly-Microsoft-centric product user, we continue promoting
the use of IE with our products, and not Mozilla
6. Mozilla retains less users from the "braindead" community

If this isn't fixed, the end result is "less Mozilla users", and for businesses
like ours, that will only continue to increase.  Understandably, you're doing a
favor for the users you know, and yourself - but removing the option, entirely,
prevents businesses (like ours) from promoting the usage of Mozilla.

Comment 20

[Doron Rosenberg (IBM)]

-> moi

Comment 21

[Doron Rosenberg (IBM)]

Attachment: Adds a dialog

I kept the js console error for now, probably can/should be removed if this
patch is accepted.

Also, someone needs to decide on the string, as we have tabs, so using "window"
isn't a good choice.

Comment 22

[Troy]

I ran across this bug just today. I see the developers are refusing to fix this issue.

IMHO this is a bug. I have a web application that needs to use the window.close() function to work correctly. A window should be able to close itself.

Comment 23

[Mike Kaply [:mkaply]]

Doron, who should review this?

Comment 24

[Jesse Ruderman]

As I stated in comment 8, there are some major problems with using a dialog.  I have an idea that would solve some of the problems associated with using a dialog: use something similar to an error page instead.  When a site calls window.close(), replace the page with a page that says "The site is requesting that you close the [tab|window]" with "close the [tab|window]" a clickable button.  Then users would still be able to decline to close the window without extra clicks, and Windows users would still be able to take advantage of Fitts' Law by clicking the window's normal close button.

Comment 25

[John G. Tesmer]

In reference to comment #8, the Porn site argument is weak and the speed argument misses the point. window.close is not about speed, it is about programmatically closing a window. 

The behavior should be that the window is closed. I can understand a simple confirmation dialog, and I personally would accept that as a solution as well.

The solution proposed by Jesse in comment 24 is valid, but in my opinon less than desirable. Why introduce yet another potentially mischevious behavior? Following the Porn-site logic, what prevents an unscrupulous Porn site designer from mimicing this new page, replacing the innocent "close" action with a link to something unexpected?

Comment 26

[Doron Rosenberg (IBM)]

(In reply to comment #23)
> Doron, who should review this?
> 

Someone needs to work on the patch, I doubt this still applies.

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #24)
> dialog: use something similar to an error page instead.  When a site calls
> window.close(), replace the page with a page that says "The site is requesting
> that you close the [tab|window]" with "close the [tab|window]" a clickable
> button.  Then users would still be able to decline to close the window without

Great idea, Jesse. I'd be happy to help with the text. We'd need to make sure that it doesn't look *exactly* like the other warning pages that were shipped with 1.5, as it's not a problem with the webpage. Another thought that came to mind was to use a <browsermessage> which similarly plays nicely with tabs.

(ccing mconnor and adding to the nomination list for 1.8.1/1.5)

Comment 28

[Stefan Seifert]

I think the page telling the user to close the window is a nearly perfect solution to this problem. The user still needs to do only one click, and the application developer get's his automated message.

The message should however not have any button to close the window, for the reasons stated in comment 8. The user should learn, that there is just one valid way to close the window, and the message should just tell him to. There is no difference for the user, wether he has to click on some button on a webpage or on the close button like every other window on his system.

Btw. I stumpled over this bug on the search for another one. My Mozilla window just vanished with several tabs open because one of those was opened by a JavaScript and closed by window.close without asking. It's nice for webdevelopers to have so much control about the users's windows, but guess how pissed I am now.

Comment 29

[Csaba Gabor]

I'd like to mention for uninitiates wandering in here that it is possible to have your favorite button close a window (not opened by script) if dom.allow_scripts_to_close_windows is set to true in about:config.  Or it doesn't even have to be a button as in the silly:
<html><head><title>I'm not here</title></head>
<body onload='top.close()'></body></html>

Unfortunately, dom.allow_scripts_to_close_windows is a global setting, so if you set it, it exposes all your windows.  Nasty.  It should really be fixed to operate on a per site basis (perhaps taking (a set of) regular expressions).

Which brings us to the dialog that is being prepared.  I would hope that it allows one to remember the current site so that the the user need not be asked again, if s/he doesn't wish FOR THAT SITE.

I think it's important to keep (convenient) automation in mind.  More and more, there will be scripts (ala GreaseMonkey, for example) that automate navigation sequences.  For these types of (often hidden) applications started from the desktop, it will be important to be able to close a window without confirmation.  Site specific settings would be very helpful here.

Csaba Gabor from Vienna

Comment 30

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not a blocker for 1.8.1, if indeed this isn't WONTFIX.

Comment 31

[Darren VanBuren]

Current nightly build of Seamonkey won't close the window (gotten from this bug). who wants milk & bugs? bug 507532 (totally unrelated)

Comment 32

[Ivar Snaaijer]

using
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 ID:2007051502

On this page are two examples right below the confirmation dialogs:
http://www.webreference.com/js/tutorial1/reference.html

The first one acts as expected.
The second one also works as expected, even without conformation dialog which is a nice smart feature. 
When i open the second link in a new tab/window, the close button does not work anymore, no message whatoever. This is highly confusing, and uncalled for. (I know the 'open in new tab' feature is handled differently than _blank, but still.) 

Also there are some interesting workarounds for closing without conformation, making the question useless. 

The UI experts should probably have made a verdict by now ... 
IMHO UI's should be consistent. A button that sometimes does not work without an apparent reason is inconsistent. 

Comment 33

[Mike Connor [:mconnor]]

If the site author doesn't handle the case sanely, i.e. by detecting that window.close() was unsuccessful, and displaying a useful error to the user, the bad UI is the fault of the site author, IMO.

But we should implement Jesse's solution at some point as well.

Comment 34

[Ivar Snaaijer]

The main reason for having this feature comes from web based solutions (intranet mostly) that show a webpage like you would show a wizard in a fat client. This normally involves a new screen, and several windows. the last button would obviously be 'finished'. At this point the user has to close the window using a different button than normal. As a technician I can understand this without much effort, but most of my users have issues with this. It is just a small thing, but they can blame it on Firefox, which is bad in any case.

Also there are small scripts capable of closing the window without asking the user for confirmation. I still have a hard time understanding why Window.Close() is bad (probably DOS or something), but that loophole will probably be plugged in the near future.

The Window.Close feature should at least be working on trusted sites (as stated earlier) half the functionality is already there, as it is possible to turn it off globally, it should be possible to allow on trusted sites.

Comment 35

[Piet]

I read all the (good) arguments and I agree with proper user training to opt for the least risky practice but the fact is that Firefox behaves inconsistent in a Microsoft dominated world. By saying that I don't argue that Firefox should duplicate all the security loopholes of Microsoft, I am simply suggesting that for consistency sake and functional page layout, Firefox should consider having a practical option to close the current tab/window from a button.

I am very pro Firefox but some arguments have me seriously consider bad loyalty. Thank you for the opportunity to add my 2c.

Comment 36

[Sean Rhea]

I have to second(+) what has been said by several here. Our site has 100,000+ regular internet application users and it becomes very frustrating when functionality is determined by what a few have decided is an annoying user experience. We have very legitimate reasons to use window.close(), so what bothers me is that someone aside from both the developer AND the user decided for both of us that they shouldn't be able to use it, despite documentation to the contrary. The fact is that a lot of things can be annoying when used incorrectly. For me, annoyance is predominently determined by inconsistent and undocumented behaviors across browsers and between versions.

For the record, I could accept a compromise to simply show the user a dialogue box asking them if they really want to close the window.

Comment 37

[Jesse Ruderman]

I talked to Sean (comment 36) and it turns out that his window is opened by a desktop application for some kind of web-based survey related to the application.  Perhaps we could add a command-line switch that his app can pass to Firefox, saying that the site is allowed to close the window as if it had been opened by script.

Comment 38

[Gérard Talbot]

Hello,
I've resummarized this bug to reflect more accurately the real issue involved in this bug.

Reference:
"Invoking the window.close method on a window not opened with script displays a confirmation dialog box. Using script to close the last running instance of Microsoft Internet Explorer also opens the confirmation dialog box."
http://msdn2.microsoft.com/en-us/library/ms536367.aspx

Testcase along with cross-browser notes:
http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/ClosingWindowsNotOpenedByJS.html

Comment 39

[Gérard Talbot]

> We have very legitimate reasons to use window.close()

Can you give a few of those reasons?

> , so what
> bothers me is that someone aside from both the developer AND the user decided
> for both of us that they shouldn't be able to use it, despite documentation to
> the contrary.

Where is that contradictory documentation that you are talking about? As far as Mozilla Developer Center (MDC) is involved, the close() method has a restriction (like any other method can have restrictions on its usage) and MDC documents
http://developer.mozilla.org/en/docs/window.close
and
http://developer.mozilla.org/en/docs/DOM:window.open#FAQ
mention the restriction on close().

> annoyance is predominently determined by inconsistent and
> undocumented behaviors across browsers and between versions.

I certainly agree with you. In late 2004, I reported the problem for IE6 
"opener property should be a read-only property"
http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerSecurity
and Microsoft fixed it in IE7 build 5296. 
I've also filed a similar bug for Opera.

Comment 40

[Gérard Talbot]

> his window is opened by a
> desktop application for some kind of web-based survey related to the
> application.

Jesse, what I don't understand is how such window could be created without a close button. How is that possible?

Comment 41

[Jesse Ruderman]

Undoing Gérard's change to the summary because (1) his summary assumes the solution is to use a prompt rather than a replacement page, apparently based solely on Microsoft's documentation and (2) he removed the searchable string "window.close" from the summary.

Comment 42

[Jesse Ruderman]

> Jesse, what I don't understand is how such window could be created without a
> close button. How is that possible?

Where did you get the idea that the window doesn't have a close button?

Comment 43

[Gérard Talbot]

> Undoing Gérard's change to the summary because (1) his summary assumes the
> solution is to use a prompt rather than a replacement page, apparently based
> solely on Microsoft's documentation and 

Bug reports should be confirmed when there is some kind of a clear description, steps to reproduce, actual and expected results. I did not create this bug, I did not describe the bug. I did not write "generates a confirmation message." in the description. I did not write "function with the appropriate confirmation dialog" in the description. I did not write "IE presents a dialog and closes the window on positive confirmation." in the description. 

Consistent cross-browser behavior is what I assumed would be desirable and best for everyone. Obviously, I was wrong in assuming that. It is not good for some people. Fine.
 
The fact that you want to create a "Please close me" secondary page is astonishing. A "Please close me" secondary page should now be assumed to be the correct expected results.

> (2) he removed the searchable string
> "window.close" from the summary.

Close was certainly in the summary that you reedited. Non-script too. Dialog also. Was I so far off?

Comment 44

[Gérard Talbot]

> Where did you get the idea that the window doesn't have a close button?

One person in this bugfile said 
"customer complains they can't close window" (1)
when clearly referring to Mozilla users. So, why they can't close the window? How can it be so difficult to close a window? Only possible explanation is that there is no close button, only a close() that doesn't work.

(1): This was said 31 months before MSIE7 first beta release fixed their opener bug. It would be interesting to see if IE7 users have no problem whatsoever.

Comment 45

[Sean Rhea]

(In reply to comment #44)
> One person in this bugfile said 
> "customer complains they can't close window" (1)
> when clearly referring to Mozilla users. So, why they can't close the window?
> How can it be so difficult to close a window? Only possible explanation is that
> there is no close button, only a close() that doesn't work.
> (1): This was said 31 months before MSIE7 first beta release fixed their opener
> bug. It would be interesting to see if IE7 users have no problem whatsoever.

I can't close a window that my windows desktop application opens through code. Why should that be considered normal behavior when I was the one that opened it? Our web application users should not be expected to have to clean up a bunch of empty windows after us and guess at which windows are ok to close and which are not. Our users expect us to guide them through a seamless transition between the windows desktop application they are testing and the web application that relates to it. Part of that transition necessitates the opening and closing of browser windows. I don't like the fact that our users expect us to be able to control the windows that we opened in the first place, but we can't. The browser doesn't know that we own the windows since they weren't opened with script. Could we ask the users to close the windows themselves? Sure, I guess...but wasn't the point of all this to make the browsing experience less annoying for the end user? You can't simply assume that all users are anonymous visitors to a public web application.

Comment 46

[walf]

One point that seems to have been missed here is that Mozilla developers assume that web developers can always ensure, 100% of the time, without error, that every page which contains a window.close() call will be reached via JavaScript alone.

This is preposterous, especially for sites/apps that are large, complex and/or need to be indexed by search engines. Furthermore, Mozilla provides an abundance of ways to open links which is great, but also hinders authors controlling how a page is reached. The effect of this is that a single window.close() call can work sometimes and not others.

Mozilla does not hold the majority in web browsers, so providing a feature that is expected, useful and has prior documentation, can only aid adoption of Mozilla products. I don't expect fancy new chrome, just a simple something.confirm()

Comment 47

[Jesse Ruderman]

Where do you see anyone assuming that?  We know that the lack of support for "window.close() for non-script-opened windows" will cause some poorly designed web sites to look broken in certain cases.  (Those sites *are* *assuming* that window.close() will always do something, which is demonstrably false).  Some of us just don't think adding support is worth the annoyance/security/usabilty hit in other cases.

Comment 48

[walf]

(In reply to comment #47)
> Where do you see anyone assuming that?  We know that the lack of support for
> "window.close() for non-script-opened windows" will cause some poorly designed
> web sites to look broken in certain cases.  (Those sites *are* *assuming* that
> window.close() will always do something, which is demonstrably false).  Some of
> us just don't think adding support is worth the annoyance/security/usabilty hit
> in other cases.
> 
i say assume because the detractors of a confirmation for these kinds of close() calls say, in this and other window.close() bug reports, that unsuccessful calls are simply a web developer design flaw. from my experience, and from other posts it seems many of the cases in which it occurs are on non-public areas or networks so don't make it into any "top 100".

the fact is that, irrespective of those people who put window.close() in any old page, developers put it in pages for a reason. it is a good feature of javascript. mozilla browsers promote user freedoms thus one can't ensure that a window which utilises window.close() will only ever be opened by script, so it makes sense to *provide consistency* by leaving the close() call in when the page is intended to be or usually opened by script.

it is frustrating to read that people have been complaining about this since at least 2002 and no compromise has been made. mozilla could at least use an information bar like those used for blocked popups: then the user would be told why it doesn't work (they're kept in the loop), the window still would not close (security and standard adherence is preserved) and no extra user input is required are required between the unsuccessful close() call and closing the window normally (usability unhindered).

it's simpler to have unsuccessful close() calls detected and reported by a browser than by every script in every page that will ever use window.close()

Comment 49

[Jose Nunez]

I think that by deviating FF from what DOM documentation states without proper explanation makes FF to be seen buggier than IE and other browsers.

Last suggestion by Lucas makes a lot of sense. Just put a message in the information bar and FF will be seen a lot better.

An additional close button or design flaw is not the only reason to try to close a window through window.close(). 

Comment 50

[Piet]

I wish I understood the psychological reasons for this thread to span so many pages... My comment is not a technical one as I opt out of following this any longer. Maybe the sad basis this has come to will inadvertently influence my choice of browser in future.

Piet Vermeulen
Developer, South Africa

Comment 51

[Mohammed Raheem]

I too would request that window.close be allowed to close windows that it did not open. We need a close this window/logout link and are not able to implement currently using my favorite browser. :(

Comment 52

[Erik Perrohe]

If you are focused on thinking about Firefox as simply "browsing the web" then the viewpoint that "the ability of a program to close the window, is not needed", is possibly justifiable.  Certainly there have been abuses of it in the past.

But I respectfully submit that there is a bigger picture to consider,  which is the use of Firefox as a rich api for implementing gui apps.  When you view it this way, suddenly there is a very legitimate and compelling need to be able to do all the normal things that a gui app does, such as closing a window.

Consider this real-world scenario.  The company that I work for has a web based app which is a direct replacment for the previous desktop app.  Typically, the user clicks a shortcut on their desktop, which takes them to the public website and clicks the login button on that site.  The login button runs a program that opens a new window with an ssl session and login form.  And the program tries to close the window from which the session was launched.

Why do we do this?  Well, there are several reasons, but the primary reason is that we want an app like window without all of the toolbars etc.  At this point we just want the browser to be a frame with our app providing all of the content.  The only way to get a window like this is to have our program open/create a new window.

But our customers are not necessarily very sophisticated computer users.  It may seem trivial to you that all that is needed is for them to click the X button to close the window that they don't want, but this view is not supported by our real-world experience with actual customers of our site.

Instead what we find is that people get very confused by the presence of two separate browser windows.  Also because our app window is now in front of the launcher window they must switch back to the launcher before they can close it.

Typically where this becomes a problem is when they switch to another program and then try to switch back to our program.  The presence of two separate browsers on their task bar is confusing.

This is a really horrible situation that has caused plenty of tech support calls.

We may not be a top-100 website, in fact we never will be because this is a specialized product.  But none-the-less this is an often encountered legitimate scenario.

The arguments about ie7 are irrelevant.  We tell our customers that they MUST use Firefox.  Did we make the wrong choice?  Perhaps we should have picked a different browser to standardize on...?   What does the w3c have to say about this issue?

From a security standpoint, there are actually three cases that need to be considered.  

1) Browser has the ability to close *any* window including windows of sites not related to it.

2) Browser has ability to close the window of the site context in which the program is running.  Even though the program did not open that window.

3) Browser has the ability to close windows that program opened. (already supported)

I believe that part of the debate about this bug is that people appear to be treating #1 and #2 as being the same thing, when in fact they are worlds apart from a security standpoint.  I think that we can all agree that scenario #1 is a really bad idea, it entails high risk.  The ability to close *any* window at any time is not what we webapp developers are asking for.

But what is the harm?  What is the worst that could happen if a site (scenario #2 above) wanted to close itself?  Please forgive my ignorance, but I just don't see the problem...  can you explain your view in more detail?  How can a site that closes itself be a security risk, maybe it's just their way of saying "no trespassing".

Yes, I know that there are viruses that are involved in click-fraud etc.  But since they are opening those windows under program control, they already have the ability to close those windows.  So enabling scenario #2 already has no affect on them because they are already covered by scenario #3.

Firefox currently has a permissions tracking system for pop-up windows.  It is domain specific, which is highly desirable.  I believe if you are still unwilling to allow scenario #2, then a reasonable compromise solution to this problem of closing the window, is to reuse/adapt the same code that you are currently using for pop-ups, in which the user is given the choice to allow the action and to save that site specific permission for the future.  But if you do this, please allow the permissions to wildcard include all subdomains of the primary domain, there are lots of reasons why the subdomain would change.

Comment 53

[Jesse Ruderman]

Erik, there are other ways to set up a desktop shortcut that opens a Firefox window without toolbars.  Your scenario is not a good argument for allowing all web pages to close the window they are in.  If there isn't an easy way to open a Firefox window without toolbars using a command-line switch, please file a bug.

Also, #1 and #2 *are* identical, since having a reference to a window allows you to navigate it so that your site is loaded in it.

Comment 54

[Erik Perrohe]

Hi Jesse,
Thank you for the response.  

Our app does not always get launched from a desktop shortcut.  We also have roaming users that could be connecting from anywhere.  

To clarify the difference between #1 and #2.  What I am referring to is that the program itself is running in a specific browser window/tab.  That program should only be allowed to interact with the browser window/tab that it is running in (plus anything it created).

Scenario #1 is saying that if the user has other tabs/windows open, then the program should not have any access/affect on them.

The way that close window works is that if there are other tabs open, then it only closes it's tab.  And if there are not any other tabs open, then it closes the browser itself.  The (very old) comments above about all the tabs getting closed, was actually a bug and in my testing I see that this no longer happens, that bug has been fixed.  Close window should only affect it's own window/tab/site and no other.


How would a program get a reference to a window/tab that it does not own?  Sounds like a very serious cross-site scripting vulnerability to me.

Why is the program not considered the owner of it's window for the purpose of being able to close it, if it is running inside of that window and has full access to the DOM including the ability to resize and minimize and change any other aspect of that window?

I would really appreciate it if someone could give a clear explanation about the security risks involved in allowing a program to close it's window.  

The only thing I came up with is that if an attacker could get someone to set their home page to a particular website, then every time you launch Firefox they close the window.  Ha ha a silly script kiddie joke, annoying as heck but certainly not a security risk.  First they would have to trick you into setting the home page, and then they could do nothing to your computer except as a very ineffective DoS attack.  

This is the worst I could come up with.  Any other scenario involves the program ceasing to exist.  It's hard to image how a program which is no longer running, is a threat.  Ditto for a program which navigates to another website, that program goes out in a blaze of glory...  :-)


I suppose that hypothetically you could pepper the forums with links that when clicked on, would cause your browser window/tab to close.  Yes, this would be annoying, but where is the motivation?  What is the payoff?   If I really want to annoy the heck out of you I will just resize your browser window to be small and then start moving it randomly around the screen.  This would be much more effective.  And I can already do this without violating any security policies.  And on top of that, it affects all of the sites/tabs that you currently have open not just the tab the program is running in.

Security is always a juggling act.  A steel door which is welded shut provides a very high level of security, but it is not particularly useful.  Especially if you need to access that room very often.

So, on the one hand we have a hypothetical threat in which the actual risk is very unclear and the actual potential damage close to nil.

And on the other hand we have a huge interference in the normal and legitimate functioning of the day to day operation of many sites and applications.  And this problem is encountered by large quantities of real-world people.  See the many comments in this bug and the *huge* numbers of duplicate bugs. (Bug 183697). and multiple forum topics in mozillazine, by the many webapp developers who have been adversely affected by this.


Shall programs never be allowed to exit? Can a website never say goodbye?

There is a premise here, an unquestioned assumption that allowing a program to close itself is a bad thing.  But I would respectfully ask that this premise be reviewed and reconsidered.  Just because somebody back in the 90's decided that it would be a bad idea for a program to close a browser, does not mean that it is an accurate reflection of real-world needs today.  Back in the 90's few if any people where thinking of using the browser as a gui api.  The paradigm of an app is somewhat different from a simple webpage.

Especially consider that all versions of IE prior to 7 have allowed programs to close themselves.  And that previous versions of Firefox also allowed programs to close it.  And that Opera still does. And no great calamity has struck us as a result.  No attacks have been noted by the various security watch sites (that I am aware of).  The forums have not been peppered by booby traps intent upon the heinous act of closing your browser.

Again I ask, where is the risk?

Yes I have seen some of the spam site attacks, and even had to clean up a few.  But those are based on their ability to open new windows, not close them.  The pop-up blocker does a pretty good job of defanging these.  Yes I have seen browser windows that make themselves as small as possible and then attempt to hide off screen.  But they aren't trying to close themselves, once closed the attack ends.

Meanwhile, real companies are paying real money to deal with the inability of Firefox to close a window.  Just a few days, ago I took a tech support call from a customer...  she barely speaks English and her computer skills are nearly non-existent. And I had to try to explain to her why she was seeing two windows and how to close one of them.  I finally did a remote control session and changed the dom.allow_scripts_to_close_windows flag, but even if we could afford to do that for every customer (we can't) it still does not solve the problem of roaming users.

Comment 55

[Jesse Ruderman]

"We have a security hole that's roughly equivalent to the security risk of adding this feature" is usually a bad argument, but it's especially an especially bad argument here given that we're eventually going to fix bug 186708.

Comment 56

[Erik Perrohe]

That is a side-track.  And in reading that bug I see that the "fix" had to be undone because it was breaking legitimate behavior.  So maybe that side-track is germane after all.  Because myself and -- from reading the forums -- dozens perhaps hundreds of other web developers have been telling you and continue to tell you, that not allowing window.close is in fact breaking legitimate and valued behavior.

We've had years of being able to close the window without any apparent calamity.  And now we can't because it *might* be misused.  

Clearly you are a lot more knowledgeable than I am about the various ways that browsers are exploited in the wild.

I am sincerely trying to understand what the problem is.  Would you please explain it to me.  How can the ability to close (your own) window be exploited to do evil?

Comment 57

[Jesse Ruderman]

See bug 402401 for an example of how being able to resize windows is abused in the wild as part of an attempt to trick users into installing malware.  The same attack would work, and would work slightly better, if sites were able to close windows.

Don't be distracted by the backout of bug 412862.  That doesn't prevent us from fixing bug 186708.

Comment 58

[Andrei]

The bottom lins is this 'bug' needs to be fixed. What smart ass decided to remove / alter window.close functionality??? huh?? 
Less talking and more fixing!

Comment 59

[Andrei]

(In reply to comment #3)
> I deliberately did not add a confirmation dialog, because I think they're
> annoying and detract from the user experience. In my mind, it would be less
> annoying for a web page to simply tell the user "Please close this window now."
> Can you point me at some of the "many applications and websites" that need to
> close user-opened windows? If there are in fact many of them, and especially if
> any of them are "Top 100" sites, I may reconsider.

(In reply to comment #3)
> I deliberately did not add a confirmation dialog, because I think they're
> annoying and detract from the user experience. In my mind, it would be less
> annoying for a web page to simply tell the user "Please close this window now."
> Can you point me at some of the "many applications and websites" that need to
> close user-opened windows? If there are in fact many of them, and especially if
> any of them are "Top 100" sites, I may reconsider.



You suck man you've made our live harder. 

Comment 60

[walf]

It's good that Mozilla developers won't budge on removing window.close() for security reasons. It makes sense to cut out all risk of malicious code controlling windows it is not supposed to. I now think "too bad" for those sites that expect it to work every time despite the standard, and that end-users are just going to have to learn how to use a browser...

/but/, no one has responded to my compromise proposed in comment #48
> ...
> it is frustrating to read that people have been complaining about this since at
> least 2002 and no compromise has been made. mozilla could at least use an
> information bar like those used for blocked popups: then the user would be told
> why it doesn't work (they're kept in the loop), the window still would not
> close (security and standard adherence is preserved) and no extra user input is
> required are required between the unsuccessful close() call and closing the
> window normally (usability unhindered).
> 
> it's simpler to have unsuccessful close() calls detected and reported by a
> browser than by every script in every page that will ever use window.close()
> 

Why can't we just keep the user informed with the yellow info bar about what's going on?
That info bar is the least intrusive way of displaying messages: it leaves pages and navigation intact, doesn't create dialogues/windows that require responses or steal focus, and can provide buttons that launch further help if necessary.

e.g. a message like "Script didn't open this window/tab, therefore script cannot close it. If you want to close it, click the close button on this window/tab or press Alt + F4  [Help]" would probably solve most issues. The example assumes the majority of users who can't figure out how to close a window/tab are on MS Windows.

Comment 61

[Sije de Haan]

I need to close the browserwindow or tab too, but for another reason: My customer wants to run the application in a window without addressbar, and the only way (known to me that is) is by opening a new window with the address bar disabled. But when we do this the login page remains, confusing the user and asking unnecessary and confusing questions.

Try it out: http://ezm.dehaansoftware.nl/EasyManage
name: ezm
pw: demo

Comment 62

[David Hamilton]

I want to propose a solution, I've read through this thread.  We work for a metropolitan government agency and want to be able to support FF as well as IE up through IE7.  In IE7, we can have the users go to a url, it will popup a new window with all menus, buttons, status bar etc... removed and close the parent window that opened it.  

One argument a developer stated was what should happen if there are multiple tabs?  Here's what IE7 does, which is really smart and you should do it here too.
  
If there are no tabs, just one window and you open a window and call window.close on the parent, it closes the parent window.  It displays a confirmation dialog but they provide a way to have it not show up if you don't want it to.   
 
If there are tabs, and you open a window from one of those tabs and call window.close on the parent, it just closes the parent tab, not the entire browser window.  

This would fix is so that companies or governments that want to run applications through browsers can still work correctly, and if someone comes across a site like this while surfing the Internet, it will only close that one tab.  

I've read through all of these comments and see a lot of arrogance and pride being displayed by the Firefox developers which did not impress myself or my colleagues when we read through all of these comments.  This is a valid issue, it is a problem that you've left sitting out there unresolved since 2003.  It works in your competitors but not in Firefox.  Why are you sitting on this issue?    

Search on google, yahoo, or any search site and you will find thousands of postings of people asking for this for many valid reasons.  I do not buy that this is a security problem if you code it the way I've suggested you will not have that problem.  

Please just understand that your users are literally begging for this feature and just implement it like you should have back in 2003.  

Thank you for your time,
David Hamilton
J2EE Architect, Data Architect, Web Developer

Comment 63

[Sije de Haan]

I forgot to mention in my remarks send in April 14: I do not only need to close the window but I need a silent close as well as is possible in IE7, the new window closes the parent or tab without a popup:

// close the parent window that created me (call with a little delay)
var caller = window.opener; // get the window that created me (the child)
caller.opener = window; // fool the caller, make it think I created it.
caller.close();

In my opinion this should work in FF as well.

Try it out in IE7 and FF: http://ezm.dehaansoftware.nl/EasyManage
name: ezm
pw: demo

Sije de Haan

Comment 64

[Alper Kara]

This is a stupid bad behavior based on wrong logic.
First of all if window is owned by user:
javascripts should not do any adjustment on any web page (effecting window).
Thus we can say that window is owned by the user but also the web page.
So web page should be able to close itself, and if you ask me (i know u don't)
the right choice will be window close it self with/without(it is applications choice) asking anything like "real world applications" (remember web 2.0), including its children.(with an option all children close when parent closes)
Secondly can you say me any security related problem about window closing itself silently, except problems about implementation which as a programmer i can understand but as a consumer i can't.
Let me say what i will do: i will say in internet explorer window closes automatically and in Firefox you should close the window yourself, and let users decide which one they use, as i have no other practical choice. This is a very big problem in enterprise environment.
Sorry if it sounds bad, or i am mistaken.

Comment 65

[Alper Kara]

Sorry about the second post,

Let me remind you something if you believe your standard is true :
"no matter how good or true, a standard can not live without users.", 
"no matter how bad or wrong, a standard can live with enough user base."

Do not make linux developers usability mistakes again, you are not developing only for professionals.

Comment 66

[Bhargav]

Hi
I am a software developer.
I have a launcher html, the only content of which is a small javascript function which looks at the argument and opens new window for application without any tool bar and then closes itself.
This html is launched using perl.

My problem is that the window opened for this launcher html is not getting closed using window.parent.close() or any other option. 
The reason I see from this thread is because of window.close will not close window which is not opened by javascript.

Is there any way to close this window programatically using something other than javascript.

Or I can get rid of this html itself if you can tell me a way to open a window without address bar etc using some other way than window.open

Telling customers to manually close this window which they have not opened is not very welcome solution. I am working on this project for a year...and even I dint know this window exists till today when I opened it in mozilla. 
I am not against or for any browser, but I have to fix this as part of my job.

Can anyone tell me the alternative..

The one solution I have found till now is changing firefox.js
pref("dom.allow_scripts_to_close_windows",          true);
pref("dom.disable_window_open_feature.location", false);

but this will change settings globally I guess..Also other problem is, this si very raw way of changing the setting. Not many users will be ok with it.
Is there any option on mozilla interface for these settings?
so that we can document it and close this ticket.

 

<html>
<head>
<script language="javascript" type="text/javascript" >

function openPimWindow()
{

if(document.location.search != "") {
    pimURL = document.location.search.substr(document.location.search.indexOf('url=') + 4)
 }
 if (self.window.name != "NMC"){
alert(	pimURL);
win=window.open(pimURL,"NMC",'statusbar=no,toolbar=no,location=no,directories=no,status=no,menubar=no,scrollbars=no,resizable=yes,height=690,width=1000');
	win.moveTo(0,0);
   window.parent.focus();
    window.parent.close();
	

 }else{

win=window.open(pimURL,"NMC",'statusbar=no,toolbar=no,location=no,directories=no,status=no,menubar=no,scrollbars=no,resizable=yes,height=690,width=1000');
	win.moveTo(0,0);
	
 }
}

</script>
</head>
<body onLoad="javascript:openPimWindow()">
</body>
</html>

Comment 67

[Frankie Dintino]

I agree with comment #54. Perhaps the issue is that what defines "opening a window with javascript" is too narrow. What is a scenario where you can get a reference to a window object but shouldn't be allowed to close it? If a malicious site has a reference to your window through some XSS issue in your code you've got bigger problems than the window being closed.

Comment 68

[Erik Perrohe]

So, here we are, *years* later,  and the Firefox Devs are still turning a deaf ear to the ***frequent*** requests from legitimate web developers.

This is extremely disappointing and reflects very poorly on the Firefox development process.

No one has yet demonstrated/explained a valid security risk caused by a javascript program which is allowed to close the page that it itself is running in.  We are not talking about being allowed to close other random tabs/browser windows.  We can even live without the ability for the child window to close it's parent.  But a window sure as heck ought to be able to close itself.  Or else there should be a totally iron clad reason why not, obtuse hypothetical potentialities won't cut it.   

Hypothetically you might get struck by lighting or fall in a bathtub.  Shall we place a ban on bathtubs???  If you are going to continue to insist that this is a dire security problem that a program is allowed to close itself and cease to run....  then please explain *specifically* what the risk is.  Yes I looked at the other bugs mentioned, but the phony crash dialog still works just as effectively even if it is not allowed to close when clicked, it could always just put the child window on top and hide itself, something that it is allowed to do.

AFAICT So far we have only heard from 2 devs, who remain adamantly immovable on the subject and have ignored all requests to even discuss a compromise.  Is there some way to kick this bug upstairs?  get some other dev opinions on this?

Meanwhile, my company has resorted to setting any and all Firefox browsers to 

pref("dom.allow_scripts_to_close_windows", true);

This is now part of the install process for our software.  Since it is a global setting it *fixes* the problem once and for all.  It is very simple to do this, I encourage other companies faced with this issue to do the same.  If enough of us do this we can make this problem go away without having to be beggars relying on the *good graces* of the Firefox devs.  

So far I have ignored google's chrome browser.  But I am starting to think that they may have had a very good reason for forking off from the Firefox dev's, maybe I should look at it after all.

------------------------

By the way, all these arguments about the user being able to click on the X are INVALID because when the browser window is made full screen via F11, the X is no longer visible/accessible on some OSes.  And don't you dare *fix* it, this is not a bug, it is exactly the behavior that web apps desire....   

This whole issue revolves around the desire to use the browser as a gui web *app*  which is very different from using it to *view* web pages.

And despite all the lip service to the contrary, the browser developers still don't seem to *get* the idea that a web app has different behavior requirements from a web page.

Maybe you never do want to close a web page, maybe it is reasonable to expect that you will just navigate to somewhere else, until done with browsing altogether.  But that is not at all how a web app behaves.  A web app should be closed after it is done.  

A Launcher page should always be able to be closed after launching the web app.   There will always be scenarios where a Launcher page is desired/required.  A launcher page can never start itself.  Therefore Firefox will never allow it to close itself.  This is very short-sighted.

Websites don't have/need launcher pages, but Web APPs do....

Comment 69

[Sean Rhea]

I'd have to agree. The process of a qualified group of professional web application developers having to prove to the Firefox developers that this is not desired behavior and then having those concerns dismissed and go unresolved for so long is the epitome of inefficiency. If you want Firefox to remain relevant to web application developers, you need to listen to the developers giving you feedback, not simply dismiss their application environments as "poorly coded" or suggest that they aren't a standard implementation of web practices. To say that I was frustrated by this process would be putting it mildly. 

I recognize and respect that security for end users is the ultimate goal, but none of the Firefox crew that have responded have ever offered forth a reasonable explanation about why allowing an application to close a window that IT CREATED is or could ever be a breach of security by anyone's definition. It just seems to me that you are tilting with windmills on this one guys...and annoying the heck out of the windmill owners in the process.

Comment 70

[Csaba Gabor]

I'm not an FF developer, but I have had occassion to want to use window.close().
Thought I'd make a summary of the issues, since it seems that it's difficult to pick out (if you just want the exciting conclusion, skip to the end).

On the one (AGAINST) side:
(A1)  Security:  (from Comment 8) Bad sites might try spoofing a confirmation dialog, and after "training" an unsuspecting user substitute a malicious dialog in place of the prior confirmation dialog.

(A2)  Data Loss:  (from Comment 28)  If the user brings up a page that closes the window, then they may lose information that exists on prior web pages in that browser window's history.  In addition, it may also be that the user navigates away from the window.close() desiring url prior to the window.close() being issued.

On the other (FOR) side:
(F1)  We need this 1:  (from Comment 29 and Comment 36)  Firefox is opened by a desktop program (whether in the foreground or background).  Thus (being a web app), it has the right and should (and ought) to close itself when done.  Not allowing this can lead to uncleaned up screens, and also to hung programs (eg. if FF is run in the background on Windows (to utilize the features of GM, for example), and the user examines running processes with Ctrl+Alt+Delete, they might not be able to identify which is the spurious FF process).

(F2)  We need this 2:  (from Comment 61)  An FF window wants to repaint itself, (generally to hide information) so as to present a developer determined look.  This is done by creating a new window and closing the prior one.  Not allowing this leads to confusion on the user's part.

The proposed solutions are:
(S0)  Don't do anything, it's OK as is.
(S1)  Have a confirmation dialog (original submission; Comment 60)
(S2)  Have FF generate a confirmation or informational web page instead of the confirmation dialog (Comment 24)
(S3)  Have a site specific dom.allow_scripts_to_close_windows (Comment 29)
(S4)  Have a command line switch allowing for window.close() (Comment 37)

My take: this issue is so ugly because there are several distinct scenarios which have not been clarified.  "We need this" is generally unhelpful without example as is citing "security risk" without example.

(A1) is too abstract for me and has not been cited as a real world example in other browsers that exhibit the Confirm Dialog behaviour.  (A2) This is a concrete, real world issue that I have experienced myself, and I concur with the sentiment of Comment 28 - I do not want any "solution" that allows a foreign web site to cause me data loss.  Ie.  (A2) is a major sticking point for me.

(F2) I can understand a site wanting a certain look, but it usually bugs me when said site wants to restrict information (that I feel I'm entitled to) such as a url.  In these cases I will do something like (there are other ways, too) hitting ctrl+t to create a new tab, and then drag the "hiding" tab to a proper browser window where it will show me the url in question.  As far as I'm concerned, this is a "want" and not a "need".  (F1)  Firefox can be run in the background on a specific page with a specific profile, though the method for doing this is not well known.  Sequencing other apps (a browser in particular) seems like a perfectly reasonable thing to want to do.  In this case, proper cleanup demands a silent shutdown.

From where I sit, (F1) and (A2) are the two that I find compelling.  (S0) I really dislike, because it trains me to distrust buttons working.  I would take (S1) over (A1) hands down, but it is not sufficient since it does not address (F1).  I think that (S2) would cause me to be more suspicious than any other behaviour since it's essentially new and is relying on this newness to alert people to a potential problem.  As I'm sure Bruce would point out, security based on that is not security.  (S3) does not address (A2) so it is out.  (S4) would address (F1) so I would support it.


However, what I would like to suggest a solution that takes (A2) into account and allows for a seamless (F1-2) in (hopefully) most cases:
(S5)  If the only domain in the browser's history (other than an initial home page) is the domain that wants to use window.close() then allow a silent closing.  Otherwise, pop up a dialog asking for confirmation.

Comment 71

[Erik Perrohe]

pretty good summary, but you missed a couple of points.

As far data loss == history loss ::  I disagree, fact is that you can totally exit from firefox and restart it and then look at your history and it will all be there.  Thus there is no loss.  There was early on a bug that allowed other unrelated tabs to be closed, but that problem was fixed a long time ago and the comments about that problem are no longer applicable to this discussion. 

Remember this discussion started in 2003 !!! a lot of those early comments are not relevant to the current situation.

---

I think maybe that you did not understand a "Launcher" and a Web *App*.

A Launcher is an ordinary web page reached by ordinary means.  You go to that page and click a button (typically the button says "Login") and it then launches a separate window containing the web app.  

There are a lot of good reasons for using a launcher, such as increasing site security.  Other uses of a launcher are to determine the screen size and create an appropriately sized window.  But the major reason for doing it is that it is the only way we can control the browser window, is by creating a separate window.

Once the target has been launched in a new window, it is highly desired to close the window that launched it.  And this is what we can not do.

While I agree with you that ordinary web pages which insist on hiding the address bar are very annoying, I do not agree with the conclusion that there are not any legitimate scenarios for wanting to do this.

There aren't very many web apps out there so it's not surprising that people don't really understand them.  And since web apps are most frequently designed for internal company use you are even less likely to encounter them.

The usual case is that we are taking a desktop app and replacing it's ~guts~ with a web page.  In doing this, it is generally strongly desired that this does not look like a web page but in fact looks exactly like the original desktop app that it replaces.  There are many advantages to doing this.

A web app is *not* a normal web page.  tool bars, address bars, status bars, etc.  these things are not appropriate for a web app.

Taken to the extreme, a web app can create a complete environment that is essentially a replacement for the operating system itself.  Your word processing, email etc. all take place inside the web app environment.

Since web apps are generally Web Services that require logins etc.  You are not going to just accidentally open one of these sites, it requires deliberate intent on the part of the user.  For instance the user has to push F11 to get full screen mode.

Address bars are meaningless for dynamic websites whose state is defined by javascript and constantly changes with user interactions that do not involve navigating to another page.  It is just meaningless screen clutter to insist on displaying and address bar whose value never changes.  And screen pixels are at a major premium; designers are constantly struggling with the challenge of fitting everything into the screen space.  Getting rid of an address bar that is doing nothing, frees up a big chunk of space that can be used for doing something.  Also, think for a minute about notepad or an email program....  does it really make any sense to have an address bar stuck at the top of that ui??  no, it just adds to user confusion.

---

Solutions:
Your summary missed one of the least controversial and least effort solutions.

Firefox already has this system for dealing with popup windows.  It puts up a special informational line and gives you the ability to allow popups for that specific site.

This functionality did not exist when this bug was first created.

The code to do this already exists,  minimal effort should be needed to adapt that code to ask for permission for a window to close itself.  End of problem, end of controversy.  a quick painless solution that has taken an absurd amount of time to get anyone at FF to listen too.

and since you say that you are not a Firefox dev....  then we still do not have anyone at FF listening....

I really urge people to check out mozillizine and see for themselves just how many conversation revolve around this issue of being able to close a window.  This is something that web designers strongly want and need.  This total disconnect between browser developers and website designers is difficult to comprehend.

Comment 72

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.