I want to close window tab after some success action, because customer don't want to close it manually
Script below
<script type="text/javascript">
window.close()
<script>
closes only the current View(), not the whole window.
But if it places in "_Layout.cshtml" at the first start the script is processed as expected. But after several redirects, and then when returning to "index.cshtml", an error appears
Scripts may close only the windows that were opened by them.
I know this is javascript defensive constraint, but I'm not good with js, and I don't know in which case this error appears and how to bypass or avoid it
To avoid annoyances and bad practice, browsers disallow Javascript to close browser windows unless they detect a clear action to do so (i.e. the result of a button press). If you're looking to close the window after some async work, its very likely you won't be able to do so.
You should try adding a popup window that gives the user the option to click a button which will close the tab if that is enough. You can add the following to the button to make it do so:
onClick="window.close()"
and it should work just fine. Failing that, try using an a tag like
Close
If you absolutely can not live without this feature, you'll need to create an extension for each browser you want to support that will close the window upon request. Beyond that, you'll need to find an exploit.
Related
Context :
I have developped an application which require authentification. This application uses events for dialoging with a server. When the server answer, some events are send to the client (UI).
Problem :
When the user close the page, it is necessary to make a logout on the server. With my architecture, it's easy to call a method which perform this logout. But i would like that the user show the logout progress before closing the webpage. In fact, i would like to close the webpage only when a specific event (for example : disconnection_success), is well received.
Moreover, it's verry important to not launcg another webpage because event is received on the first webpage when the logout is successfull. (Because dialog is done throw XMLHttpRequest)
Test :
I already do some test using onbeforeunload but it seems that is difficult to customize the popup.
Do you have some ideas to resolve the problem ?
BR
There are some issues with this, but you're on the right track. You're right in that you should use onbeforeunload because it is the only event that you can have triggered upon the closing of the browser window. (I know you can use onunload but at that point you have no time to do anything.) The issue here is how much code do you want to execute. The onbeforeunload doesn't allow you much time before it starts to unload the page.
BTW, there are two different scenarios with onbeforeunload:
If you return a string inside the onbeforeunload event, it creates the pop-up that you were referring to. The issue here is that with the pop-up, you won't have enough time to execute code
The other option is not returning anything. Instead, call your logout methods. This should give your code enough time to execute before closing
I actually had a question very similar to this and ended up solving it myself: How to logout during onbeforeunload/onunload using Javascript
In your question you state that you want to have a progress bar displayed when they log-out. This is impossible to do when the user closes the browser. At the moment they close their window, you have lost all control, except for in the onbeforeunload (and onunload but don't use this), and that is why your code needs to be executed there. With that being said, you could anchor your logout button (I'm assuming you have one on your application) and have it display the progress bar.
Just think about what could happen if you actually did have that kind of control - where you could pop up windows and progress bars when the user is trying to close their browser window. You could pop up anything and restrict the user from having any reliable functionality. That is why it was programmed that the onbeforeunload (and unload) events are the only ones possible to access the closing of a browser. These events have some pretty strict guidelines to them that prevent any kind of possible mis-use. I understand the problem you're having, I was there and it stinks, but I think that is your only option if you were going to use onbeforeunload.
I have a website with master page. I want to catch a user trying to close the browser/tab. When I try using onunload in the body tag, it fires not only when I try closing the browser, but also when I navigate to another page.
Any idea how to only catch the event of closing the browser?
That is not possible. Javascript can only determine if the page you're on closes. If Javascript could determine whether other tabs and windows you're on closed, for example knowing if you closed down Facebook or Flyspray, that would be a major security risk. That's now how javascript works.
I am working with a secure wizzard online, that will save data through the process, and I needed to detect wether the client closed the tab and/or the browser, so far everything was going allright until I clicked the "continue" button to proceed to the next step, it threw me the same message, I've done quite some research on this and there is no way I'll be able to ignore the unload event that occurs when I navigate away from the pagethrough a link.
I tried to use the
if(window.event.clientY < 0 && window.event.clientX < 0){
alert('holy damn! the window is closing!')
};
and some other methods that are around the web. none of them will be able to detect only the browser closing. So as far as my research has advanced, there is no way to do this.
when i try to
window.open()
in IE 9 , it opens it with favorites sidebar (if it was present in parent window) this is behaviour unique to IE , and it breaks dialog windows as I envisioned them. Any hope to fix that?
Since you specified that you're using this for a dialog, I feel I should discourage this. Using window.open() is not ideal for creating dialog boxes.
Some browsers will ignore your 'new window' request, and open it as a new tab. This can be configured by the browser user, so is out of your control.
If the user has toolbars and side panels open, there's a strong likelyhood of them showing up in the new window, which will mangle your layout. Again, you'll need to test this in every browser, and even then you can't be sure without knowing all the config options that might affect it.
Opening a new window does not give you a modal dialog box. You can't prevent the user from clicking back to the parent window and ignoring the dialog box.
Therefore, if you want to make a dialog box, you would be much better off using a javascript library that opens a box inside the current page. It's much more flexible, and gives you much more control over the end result than window.open().
If you're using JQuery, you might want to start by looking here: http://choosedaily.com/1178/15-jquery-popup-modal-dialog-plugins-tutorials/, but there are stacks of others available (it's a very easy thing to write, especially in JQuery, so there's plenty of plugins out there you can try till you find one which is perfect for you)
Try changing it to window.location.href= 'url + target="_blank"'
Hi unable to open window.open on page load in ie8 If I use window.location its not opening in new page please help me out of this.
This is because you're running into the popup blocker. This is a Good Thing(tm) :-) You can only open popups in response to the user taking an explicit action, like clicking something (and then typically only from within the event handler itself), not on things like page load where the unwitting user could be (and historically has been) inundated with dozens of windows opening all over the place. (And even doing it in response to an explicit user action may not be allowed by some blockers.)
Are no-one seeing a big problem with running window.open(window.location.href,'_blank') in the onload handler?
This is systematically a recursive function which would continue until the user manages to close the new window prior to the onload handler running.
I'm not saying that this has anything to do with the problem it might just be that IE8 is clever enough to see this..
How can we detect when a user opens a new window. The user is already authenticated and we make heavy use of sessions.
We were trying to avoid Ctrl+N javascript hooks but maybe that is an option.
I am assuming the request is the exact same URL...with Ctrl+N?
We were trying to avoid ctrl-n javascript hooks
Forget it. Whilst you could in theory try to catch keypress events for ‘n’ with the Control key modifier, there are any number of other ways to open a new window or tab which may be more likely to be used, and you won't be able to catch. File->New Window/Tab, middle click or shift-click link, middle click back/forward buttons, right-click-open-in-new-window, open bookmark in new tab, double-click browser icon...
The user is already authenticated and we make heavy use of sessions.
That shouldn't be a problem in itself. I guess what you mean is that your application is dumping all sorts of page-specific data in the session that it shouldn't have, and now you find the application breaks when you have more than one window open on it? Well, commiserations and happy rewriting.
In the meantime about all you can do is tell the user “please don't try to open two browser windows on the same application”. There are potential ways you can make JavaScript on one page notice that JavaScript is running on another page in the same domain at the same time, generally involving using document.cookie as a inter-page communications conduit. But that's also a bit fragile.
If opening a new window causes a problem in your application, then you should fix the application code to handle it instead of trying to apply an inconsistent and unreliable client-side "bandage". That's my opinion.
Why?
And anyway you can't detect it. User can open new window not only with Ctrl+N but also with File->New Window.
You could possibly put a window count into the session and increment it on window.onload and decrement it on window.onunload.
Imagine me tutting, sucking air through my teeth and going "better you than me, guvna" if you use that, though.
What I have done to solve this issue is when the user authenticates set the window name on valid login.
<script>
window.name = 'oneWindow';
</script>
And then on the master page do a javascript check:
<script>
if (window.history.length == 0 || window.name != 'oneWindow')
//history length to see if it's a new tab or opened in a new window 0 for IE, 1 for FF
//window name to see if it's a CTRL + N new window
</script>
If the check is true then hide/remove the main content of the page and show a message stating they are doing something unsupported.
This works when your login page is not tied into the master page.
If you do not have a master page then I would suggest putting the check on all your pages.
Yes and no,
You'll always see it if a control has focus, else the event is sent directly to the browser and the code on the page never hear about it.
In my experience you can't hijack the browser's shortcut, your mileage may vary. You are likely to know it happened but the browser will do its thing (for obvious reason)
In most browsers, the effect of Ctrl-N is to open a new window at the same URL as the old one and associate it with the same sessionID.
Your best bet would be to modify the back end code if possible and allow for such things. Breaking the browser's feature is never a good thing.