We Keep Coding

I want to skip showing the message when calling Office.context.ui.displayDialogAsync() method

I'm coding an Outlook Add-in.
I want to show a dialog message by using displayDialogAsync().
But when I use the method, the confirmation message is shown, before displaying a dialog (I attached a screenshot).
Are there any solutions for skipping this message?
screen shot : the message when a code calls displayDialogAsync()
・reference
https://dev.office.com/docs/add-ins/develop/dialog-api-in-office-add-ins
function openWindow()
{
var startAddress = 'https://localhost:44303/AppCompose/Sample/Sample.html';
Office.context.ui.displayDialogAsync(startAddress);
}

The message is necessary to prevent pop-up blockers. So no, there is no way to skip it if you use pop-up mode. However, if your page supports iframing you can pass the displayAsIframe=true parameter (see documentation); this mode doesn't show the extra confirmation because it is displayed as a floating div with an Iframe (as opposed to a new window).
Important: I see you are using the API in Office Online. Please be aware that we have not yet officially updated our documentation and samples to state that it's supported so you might see some bumps along the way. I expect everything will be in place by early next year.

In Outlook Web Access, use window.open() instead of the Dialog API. This will allow you to launch a child window without displaying this dialog. There are some caveats, though:
The URL of the window being launched must belong to the same domain as your add-in. Otherwise, you may see a popup blocked warning.
Firefox will show a popup blocked warning if window.open() is not called as a direct result of a user action. If your add-in's users may be using Firefox, just make sure that when launching a new window, that you're doing it directly within an onClick handler or something, not via a Promise or an async callback.
In Outlook desktop apps, the Dialog API works as expected, and in fact, using window.open() will always trigger a popup blocked warning.
Our add-in has logic similar to the following:
function launchDialog(url) {
if (/WebApp/.test(Office.context.mailbox.diagnostics.hostName)) {
window.open(url);
} else {
Office.context.ui.displayDialogAsync(url);
}
}
Hope this helps!

_blank got blocked as pop up how can i prevent this?

I have created a pdf on the server when i use:
function GetPdf(document) {
//Stores the data and creates the html,pdf file
$http.post('createpdf/', document).success(function(data){
console.log(data.filename);
window.open('download2/'+data.filename+".pdf", "_self");
});
I get a error message pop up blocked in google chrome.
When i use the option enable pop ups for this website it all works fine. Is there any way around this ? Because this could be confusing for some users.
But when i use:
window.open('download2/'+data.filename+".pdf", "_self");
It opens the page without warnings but then the main application is replaced by the pdf which is not the result i want to have.

Browsers have strict rules about when they allow JavaScript to show a popup, but they can be summarized as "Only in response to a user action".
Receiving a response to an HTTP request is not a user action, so popups are banned.
The simple solution here is to not use JavaScript. The point of Ajax is to communicate with the server without leaving the page, but you're going to leave the page anyway so there isn't really any point in using Ajax.
Just use a regular form submission.
<form method="post" action="createpdf/" target="_blank">
… then have the server side script redirect to the URL of the created PDF instead of returning the URL as JSON.

I guess you are using and external JavaScript library, I had the same issue on another Project, I used target="_tab" and it worked, I found this on this question.
It's the way Chrome handles popup calls from JavaScript when you use libraries, I used Moment.js to trigger a similar event and got the same issue.

Pop up blocking is not an issue, but a native browser feature that protect the users from popup-hell.
I would recommend to open the PDF in a modal popup instead of a new browser window.
With some jQuery code it is quite easy to implement: documentation is found here

You can always use an alternative route, for example instead of window.open function. You can use the window.location function, perhaps. Windows.location.replace which will relocate you in the same tab.
<script type="text/javascript">
<!--loc can be any changed to your window-->
var loc = "https://google.com/";
window.
window.onclick = function() {
window.open(loc);
}
</script>
Try that :)
window.open is being blocked because you are doing window.open without a click function. Most web browsers will block this feature for security purposes.

Prevent iframe from adding browser history

I have an angularjs app running within a third party iframe (i.e. different domains). All the routing and navigation within this app will add entries to the browser history, but I'd like to disable this app from do so. After much research, it seems that making use of the html5 history api is my best chance at this.
This reference makes use of a solution which essentially, onclick of a link within an iframe, will replace the current history state (history.replaceState()) with that of the links destination url. Thus the browser will not add a history entry if the current url is the same as the destination: http://www.webdeveasy.com/back-button-behavior-on-a-page-with-an-iframe/
I'm trying to implement a similar solution within an angular context which uses the ngRoute module for all navigation. With that said, I think adding a handler for the $routeChangeStart event is one solution, but it doesn't work:
$rootScope.$on('$routeChangeStart', function(e, cur, pre) {
history.replaceState(null, null, $location.absUrl());
});
In the above, this event handler appears to execute prior to navigation taking place. The absUrl is a path within the iframe app, and is the destination of the route, however the browser is still adding entries. Any ideas why?
EDIT:
So I found a partial solution. Much of the app navigates using $location.path(myPath). If I add replace() onto the $location.path() then this tells the browser to replace the history entry instead of adding a new one.
This seems to work for all navigation which makes use of $location.path(), but not for user driven navigation (i.e. clicking links); I need to find a solution for those scenarios.

PrimeFaces ViewExpiredException after page reload

I have wrapper PrimeFaces.ajax.AjaxResponse to handle ViewExpiredException (reloading the page):
var handleViewExpired = function (viewId) {
window.alert('${msg.ajax.viewExpired}');
window.location.reload();
};
However, sometimes I got that error over and over again after trying to click anything invoking AJAX requests on the site:
javax.faces.application.ViewExpiredException: /tree.xhtmlNo saved view state could be found for the view identifier: /tree.xhtml
at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:128)
Am I doing refresh in wrong way? What should I do to invoke full page reload, such as clicking reload in browser? Do I need to remove cookies (JSESSIONID, oam.Flash.RENDERMAP.TOKEN)?
I'm using PrimeFaces 3.5 with MyFaces 2.0.7 running on WebSphere 7.0.

If you have many (>15) pages/views/frames that are concurrently opened in the session, then, the following may be useful.
You need to have a look on:
1. numberOfViewsInSession: defines the number of (top-level) view states (pages) to support back button operation
2. numberOfLogicalViews: defines the number of logical views (frames) that can present in a page (per top-level view)
A quick action to make sure if it's relevant is to set those numbers to 500, and see
If they are relevant, then, you can find more information in the following links:
http://www.java.net/node/681211
Problem with numberOfViewsInSession and multiple tabs

Creating a tweet button without opening a new window

I'm looking to add a "tweet this" button to a site. Simple enough, right? The catch is that the site is meant to run on an embedded platform that doesn't particularly handle popup windows, so I'm trying to do everything inside the page.
I'm able to successfully create my tweet button, attach an onClick handler to it, and construct a proper twitter.com/share URL for the relevant content. All works fine when I open that URL in a new window with window.open. However, if I try to open the URL in an iframe, nothing loads inside the frame. Even loading http://twitter.com into the iframe fails in the same way. However, loading Google or any other website seems to work just fine.
Any thoughts on what I'm missing here? Thanks! --zach
Edit:
Yep, they are detecting the iframe on load and blanking the page:
if (window.top !== window.self) {
document.write = "";
window.top.location = window.self.location;
setTimeout(function(){ document.body.innerHTML='';},1);
window.self.onload=function(evt){document.body.innerHTML='';};
}
Any reasonable way to get around this, or am I stuck writing my own auth pipeline through oauth? I don't need anything from their API, just letting users tweet to their own accounts.

Twitter (like Stack Overflow) is probably using some Javascript to ensure they're not being presented in an iFrame:
if(top!=self){
//hates you
}
I ran into something similar recently, and ended up re-doing part of my app without the iFrame element.

Go and get a developper account on twitter and things are made easy for you :)

Can you simply redirect the the twitter share URL? I'm guessing they want to be careful about opening the window in iframe's to prevent malicious sites from tweeting in a user's account without giving the user a chance to first confirm their intent to send this tweet.

You said window.open worked fine for popping up the url in a new window but have you tried popping it into the parent frame?
twtWindow=window.open([url],'_parent',[specs])

#yuval Unfortunately for you, the twitter url goes to a page that has the X-FRAME-OPTIONS:SAMEORIGIN header set in the response. It's not a Javascript check. The browser will simply refuse to render the page after seeing the header. This is done to prevent a clickjacking attack, usually done to steal a user's password.
So your only other option is really to redirect your current page with window.location.href=url.