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.
see bug 183697
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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).
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.
Status: NEW → ASSIGNED
Thanks Mitchell, I'll look forward to your comments. Jon
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
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://22.214.171.124/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.
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.
> 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.
OK, I haven't seen any evidence that this is breaking a lot of web apps, do I'm marking it Wontfix.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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
*** Bug 202955 has been marked as a duplicate of this bug. ***
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".
Assignee: security-bugs → doronr
Status: REOPENED → NEW
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.
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.
Doron, who should review this?
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.
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?
(In reply to comment #23) > Doron, who should review this? > Someone needs to work on the patch, I doubt this still applies.
(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)
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
Not a blocker for 1.8.1, if indeed this isn't WONTFIX.
Flags: blocking1.8.1? → blocking1.8.1-
Current nightly build of Seamonkey won't close the window (gotten from this bug). who wants milk & bugs? bug 507532 (totally unrelated)
using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:126.96.36.199) Gecko/20070515 Firefox/188.8.131.52 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.
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.
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.
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.
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.
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.
Summary: window.close() does not generate a confirm dialog for non script owned windows → window.close() for non-script-owned windows is ignored (should create a dialog or "please close me" page)
Whiteboard: Proposed UI in comment 24
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
Summary: window.close() for non-script-owned windows is ignored (should create a dialog or "please close me" page) → Attempts to close a non-script-initiated window should prompt a confirmation dialog
> 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.
> 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?
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.
Summary: Attempts to close a non-script-initiated window should prompt a confirmation dialog → window.close() for non-script-owned windows is ignored (should create a dialog or "please close me" page)
> 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?
> 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?
> 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.
(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.
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 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().
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
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. :(
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.
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.
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.
"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.
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?
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.
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!
(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.
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.
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
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
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
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.
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.
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.
Assignee: doronr → nobody
Component: Security → DOM
QA Contact: toolkit → general
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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.