A simple test: if I open developer tools on this page and run this command in Chrome:
window.open('https://stackoverflow.com/', 'newWindowName').document.readyState
I see the output:
"complete"
which looks wrong to me since the window clearly didn't load yet. I see more sane output in other browsers - I checked Firefox and IE.
My question is: is there any other way to be notified when a created window's DOM is ready in Chrome? It's not cross origin, so I should be able to access the window's properties. Also, I'm aware that there's the DOMContentLoaded event, but it fires only once, and doesn't work again if I re-use the same window (in my example, using the name "newWindowName") to get notified when a new page's DOM is ready.
I wrote a code for onbeforeunload. It works for IE but not for any other browser.
var unloadFunction = function(){return "";}
window.addEventListener('beforeunload', unloadFunction);
What can possibly go wrong with this code. :( I am not able to understand. I want this to work in all browsers in order to show a confirm popup to the user before one exist the page.
Before unload processing has been modified since it was introduced due to badly behaved web pages. In result, browsers may or may not suppress alerts during unload event processing.
Refer to MDN for detailed information, but note the returnValue mentioned is a property of the event object, not a value returned from the event handler function.
The example below runs in major browsers and IE (for windows 10 at least).
Firefox and IE reported the message provided in event.returnValue.
Chrome ignored the message and simply asked
Leave site?
Changes that you made may not be saved.
Only IE showed the alert box.
var unloadFunction = function( event){
event.returnValue = "do you really want to leave this page";
alert("unloading");
};
window.addEventListener('beforeunload', unloadFunction);
LIVE DEMO
Given a URI of a file, I'd like to open it in a new tab (not a new window).
It looks like it is not possible to use $window.open(uri, '_blank').
So, I tried the following trick:
var link = angular.element('');
angular.element(document.body).append(link);
link[0].click();
link.remove();
and it works.
But, if I put exactly the same code in a promise callback, it doesn't work anymore (it opens the file in a new window instead).
Any idea what's going on here?
PLAYGROUND HERE
From your code/content, you can't force the browser to open a new tab (rather than a new window, or vice-versa). It's up to the browser settings to force it one way or another.
Anything else would be a security risk.
Let us understand fundamental how pop up blocker work.
If user trigger the function to open a new url, then pop up blocker will allow it(it should applied to any modern browser - at least firefox, chrome)
If not from user (like javascript function in background, promise or any other function trigger not from user), browser will block unless user whitelist the site manually.
This is not working.
function openInNewTab() {
window.open('http://stackoverflow.com','_blank');
}
openInNewTab();//fail
This is working
<h1><button onclick="openInNewTab()">Open In New Tab - working</button></h1>
I created simple plunkr version - http://plnkr.co/edit/QqsEzMtG5oawZsQq0XBV?p=preview
So, to answer your question. It is impossible unless user authorize it (user trigger it or white listed the site).
Quote from firefox -
Pop-up windows, or pop-ups, are windows that appear automatically
without your permission.
https://support.mozilla.org/en-US/kb/pop-blocker-settings-exceptions-troubleshooting
*Open in new tab / new windows not make any difference. Pop up blocker will still always block. It doesn't means that browser will allow if open in new tab. It is just coincidentally for certain browser default the settings in that manner.
Workaround
You can ask user explicitly to trigger the function to open in new tab after the background execution.
You can display message in UI to ask user to open the url.
Example - http://plnkr.co/edit/iyNzpg64DtsrijAGbHlT?p=preview
You can only open new windows inside click event handlers fired by the user.
The reason for this is usability.
I'm not sure if all browsers have this behavior but some browsers do not allow scripts to open windows without the user being noticed. Imagine when you visit a web page and suddenly, the web page opens several windows => it's annoying.
See this DEMO (tested with my Chrome and Firefox), even we trigger click event by script, the browser still blocks the popup.
$("#test").click(function(){
openInNewTab();
});
$("#test").click();
You cannot open a new window inside your ajax success callback because your ajax success is run in another cycle after the click event handler has finished its execution.
See this link for a workaround
if I put exactly the same code in a promise callback, it doesn't work
anymore (it opens the file in a new window instead).
I'm surprised that you're still able to open a new window. But this problem really has a lot of things to do with click events fired by the user.
Your problem is two-fold, and both folds tread on uncertain territory.
In the old days of browsers, window.open did exactly that – open a new window. That's because the concept of tabs hadn't been invented yet. When tabs were introduced, they were treated exactly like windows to improve compatibility, and that tradition continues to this day. That, and the fact that window.open was only standardized very recently, means that JavaScript cannot distinguish between windows and tabs.
There is no "normal" way to specify whether a link should open in a new tab or not. You can use the following hack, though: specify a custom window size to the open call (via the third argument), like so:
window.open('http://example.com', '', 'width=' + screen.width);
This will cause almost all browsers to open a separate window because tabs cannot have custom sizes.
In JavaScript, there are trusted events and untrusted events. Trusted events are, for example, legitimate clicks on a link by the user, whereas an untrusted event would be a manual click() call on a link.
Only trusted event handlers may open new windows/tabs. This is to prevent client-side attacks that crash the browser or confuse a user by rapidly opening a hundred tabs on mouseover or something similar.
Your second example doesn't work because the popup blocker blocks the untrusted event that you triggered via the click(). Although it was caused by a real click, the asynchronous call in-between severs the link to trustedness.
working version
$http.get('https://api.github.com/users/angular').then(openInNewTab());
EDIT----------------
Do not know why but a click() method called from a callback function acts differently than calling it straight.
You can see it here with a set interval example.
That is why I had call the function directly rather than going through a callback.
see it with timer callback
or you can use $window service please see here : http://plnkr.co/edit/8egebfFj4T3LwM0Kd64s?p=preview
angular.module("Demo", []).controller("DemoCtrl", function($scope, $http, $window) {
$scope.uri = 'http://martinfowler.com/ieeeSoftware/whenType.pdf';
function openInNewTab() {
var link = angular.element('');
angular.element(document.body).append(link);
link[0].click();
link.remove();
}
$scope.works = openInNewTab;
$scope.doesntWork = function() {
$http.get('https://api.github.com/users/angular').then($window.open($scope.uri));
};
});
For us the following worked well: http://blog-it.hypoport.de/2014/08/19/how-to-open-async-calls-in-a-new-tab-instead-of-new-window-within-an-angularjs-app/
In short: We remember the reference to the new window and changing the location afterwards.
I'm trying to do something every time a new tab opens up, both via firefox starting and when a new tab is added after firefox starts. I've been following the example at:
https://developer.mozilla.org/en/Code_snippets/Tabbed_browser
So I have
var container = gBrowser.tabContainer;
container.addEventListener("TabOpen", tabAdded, false);
container.addEventListener("TabClose", tabClosed, false);
function tabAdded(event) {
alert("tabAdded!");
var browser = gBrowser.getBrowserForTab(event.target);
browser.pollingService = new PollingService(createGuid());
browser.pollingService.start();
}
And I have a similar function for the close. This works fine for when tabs are actually opened/closed, but I've run into a couple of problems.
Firstly, when Firefox opens, it has that initial tab already open, but the tabAdded event never fires for it. Similarly, when I shut down firefox, it never fires the TabClose for those tabs.
It seems like the correct thing to do in this case is to go through all of the tabs that are in the gBrowser.tabContainer and add my service to them as well, and do something similar for when Firefox closes. Unfortunately, I'm not quite sure how to hook in to know when Firefox closes (It's also possible there's a much better way to handle this, but I can't think of one).
Secondly, gBrowser.tabContainer can be uninitialized sometimes when my initialization script runs; is there a particular event I should be listening to to know when I can safely add listeners to the tabContainer?
Use a load event listener to give the window time to be ready for you to add your Tab event listeners and create the polling service for the existing tab. Then use an unload event listener to do your cleanup.
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..