Imagine if JS could just close your browser window will-nilly!
Again, though, you have to look at the original reason you were asked t build it this way. What was the advantage/purpose of the app opening in the new window?
What if the client has blocked new windows? Oooh, you'd be closing their browser entirely!
What if they had other tabs and stuff open in that browser? What if they logged into your app while downloading something from another site??
If there's some other reason, then maybe a whole different solution could tackle that. Like removing old pre-login information? Have the server clear and refresh that page, or present a different page, or something (in the old window).
@poes....well i discussed the pros and cons of popup etc prior to developing the web app but like they say client is always right. i can imagine if the user has popup blocker. it would be a chaos :P but still lets hope for the best and until we make it live we won't get the feedback.
Except if through the client's ignorance, it causes the client to lose customers/visitors. At the very least, make them sign a paper saying they insisted on it, so they can't turn around later and blame you the developer for losing customers/visitors.but like they say client is always right.
Though if your client is selling products or wants people to use an online app, it needs to be the fewest amount of work for the visitor. Similar to online sellers trying to get the product in front of the visitor with the fewest number of clicks on their part.
I just got this book... Rocket Surgery Made Easy by usability expert Steve Krug (the guy who wrote Don't Make Me Think!). The book is about dirty/cheap usability testing for the rest of us, who don't spend a bazillion euros on some usability expert to come along and say our app is crap. He states repeatedly over and over, test early and often. Our intuition is to wait til there's actually something working, something to test. He says it's BAD intuition. Test sooner than you think you want to. It's easier to change stuff before building it all. If your testing showed users were getting blocked from the app, the client may demand that you do it completely differently... and you'd rather get that demand in the beginning instead of after spending all that time building it.and until we make it live we won't get the feedback.
If this is more of an internal app, well, the users won't have a choice anyway : ) muhahahahaha... you can afford to be more evil then.
As Paul already said, all those things you listed count as the third parameter, and simply are all enclosed in ONE set of "
window.open("home.php","_blank","toolbar=no,location=yes,directories=no,status=no,menubar=no,scrollbars=no,resizeable=no,copyhistory=yes, width=1280, height=800");
And as mentioned before, you may want to adjust the width and height to accommodate browser chrome.
For example if I'm making a min-width screen of 800px, I actually set it to 760px, which we can call "800-friendly". It may still be too small for someone with one of those goofy menu thingies on the side of the browser (I hate them but other people have them open regularly) but it'll cover most people with a scrollbar and some add'l stuff most of the time.
So your 1280, if you want 1280 to fit on some screen (and of course it won't fit on all screen anyway, may be too small of a screen!) then try 1240 or so instead.
I don't know if there's a shortcut, but if there were multiple calls to this function then I suppose they could be pre-defined somewhere else in a var.
*edit I don't know why there are spaces in my "resizeable" but they're certainly not that way in my edit!