When writing JS, the browser will often appear to block the window.open code written with JS, but it is not always blocked, it will only block the window.open in a particular case.
Because it is impractical to prevent window.open code from being blocked by the browser by default, observing the Chrome browser's window.open blocking situation is summarized below:
Browsers do not block user-initiated window.open methods, and browsers generally block window.open that are not actively initiated by users.
Here's a question, what do you mean the user is actively initiating?
The following code in the execution process is the user actively initiated
<a href= "window.open (' http://www.baidu.com ', ' _blank ');" > Baidu </a>
The following code is considered to be non-user initiated during execution:
<a href= "javascript:settimeout (function () {window.open (' http://www.baidu.com ', ' _blank ')},2000);" > Baidu </a>
That is, after the user triggers an event, the window.open performed by the event handler will be considered reasonable and will not be blocked, but if it is executed asynchronously then the window.open will be blocked by the browser because the browser does not think it is initiated by the user's main branch. But the JS code itself. This involves the JavaScript front-end code will often use the AJAX call, if the use of Ajax with asynchronous execution (the default is asynchronous execution), then the window.open will be often blocked. The solution is to set up Ajax as a synchronous process.
$.ajax ({ false// is setting this most critical Ajax synchronous ' POST ', + "/sales/submitbank", data:orderpost, function(datas) { = datas; }
The above description also applies to form submission
DWR can overwrite parameters directly:
Async:false can
Browser blocks new windows (window.open or form submissions for new windows)