I have developed a very basic Outlook Web Add In, with the purpose of loading a Power Apps app by using an iframe object with a URL pointing to the app, all this from Office 365 on desktop devices.
It works as intended and, when loading, Power Apps asks the user to login first, this isn't the app itself asking to login, but Power Apps asking the user to identify first and then loading the app. This also works, at least on some devices.
It has come to my attention that some users can't make it past the login request, as instead of opening a browser tab and showing the login form, the iframe in the Add In, shows this message, which, obviously, makes users think the app isn't working:
This app isn't working. Refresh your browser or try again later
Apparently this message is not that uncommon and at least from what I've read it isn't clear enough either.
Besides that, Windows is displaying this message:
You'll need a new app to open this about link
I'm not even sure what it means, but it shows a list with zero apps that can open this "about link", and the option to go the Windows Store.
What should happen (and happens on some devices):
User is shown login request (by Power Apps)
User logs in
App is loaded and shown to the user
What happens (only on some devices):
User is shown login request (by Power Apps)
Windows can't open a web browser, so the user can't log in
Message saying app isn't working appears, because app was never loaded.
As I don't quite understand why this only happens on some cases, I have been testing the issue, and I have found that when the Power Apps login button is clicked, a file called ielowutil.exe, which apparently stands for Internet Low MIC Utility Tool, is executed before the web browser is shown with the login screen, and this only happens on the devices that can eventually load the app, the ones that fail never run this program.
From what I understand this file is related to Internet Explorer.
The Outlook Web Add In is already working within a web browser, according to Microsoft the browser is chosen automatically (Browsers used by Office Add-ins), so if it's already opened then I don't quite understand why it can't open a new tab/window.
The combination of system requirements for Office Add-ins and Power Apps may be the cause of the error here. While some combinations of platforms and Office versions still support IE 11 for add-ins and may default to opening URLs in IE per Browsers used by Office Add-ins and Support Internet Explorer 11, it looks like IE is no longer supported by Power Apps (see Supported browsers for running Power Apps).
For users who experience the issue you mentioned because of IE, you may need to add an alternate experience for the add-in to gracefully fail (see Determine at runtime if the add-in is running in Internet Explorer) or consider a different solution for hosting the Power Apps app.
Related
In developing our passkey integration I'm encountering unusual behavior in Chrome on Windows.
On my PC, when I register a new physical key I see this Windows dialog.
When I enable the virtual authenticator environment in the Chrome Dev Tools I get this Chrome dialog instead.
However, someone testing the application for me on another PC, without using the virtual authenticator environment, gets the Windows dialog first. If they click Cancel in the Windows dialog, then they get the Chrome dialog.
Is there anything I can do to nudge the browser towards delivering a more consistent experience? I'd rather always show the Chrome dialog if possible.
For reference, this is the virtual authenticator environment in the Chrome Dev Tools:
The problem is that lots of enterprise users have to use a physical security key one or more times a day. So there's a strong desire not to put extra clicks in their way and thus to jump directly to the Windows system UI. But the Windows UI doesn't support using phones as authenticators, so sometimes the browser UI is needed as hitting escape is quite non-discoverable.
Quite how that balance is struck has varied over time and might change again in the future. You can see the current logic here if you want to craft requests that trigger the browser UI. But the intent is that sites should do the obvious thing and the UI should be fairly reasonable.
I have a simple webapp that I am showing as an app in Teams. I have set it up in App Studio and everything works as I expect and it's all great. It is showing my web app and that is what I want.
For some cases, I need to redirect to a different web app on a different domain. When testing from Microsoft Teams in my browser, it works fine. But when I test from Microsoft Teams in the desktop app, then the screen just turns grey when the redirect was supposed to happen.
I already added the domains to this dialog in Manifest Editor.
Because the screen just goes grey with no explanation, I am having a hard time troubleshooting this issue.
#NielsBrinch Could you please take a look at Redirect across domains in a Microsoft Teams tab? Also please make sure that the tab you want to redirect to, is iframable and that it meets all the Requirements for tab.
I'm working on an Outlook addin using the new Office-JS apis, and in building out the authentication flow, I've found that in the Outlook 2016 for Mac case, the dialog system seems to not work properly.
To be clear, we're using the Office Insider Fast Track build as it has much improved support for the Office-JS API.
I've been through several iterations of this particular piece (most of which worked fine both in the Windows client and the web client on Mac and Win), and have had no luck. The scenario is:
List item
Open up the task pane in outlook.
Hit the sign in button
A new window opens, pointed at our authentication portal
User signs in.
On auth completion, the window redirects to a page in the office add-in scope, and calls back to the parent frame with the auth token, where it can be further processed.
Steps 1 through 5 work fine on all platforms. Step 6 refuses to work on Outlook for Mac. Initially, this flow was built using the native js window.open and window.postMessage apis. As mentioned above, this worked everywhere but Outlook Mac, where, the API seemed to ignore the window options and just open the url in a new tab in whatever browser was open and never setting the child window reference (result of window.open being null).
Failing this, I followed the advice found here on SO to use the Office functionality, displayDialogAsync and messageParent. After some initial hurdles, this too was setup and working on every platform save Outlook Mac.
As there is no dev tools or JS console support in Mac Outlook, I followed the advice found here Howto: Outlook 2016 for Mac - Debugging/View Console Logs in Outlook Add-in and setup Vorlon to attempt to get some context, adding numerous logging points to try and get some context. Unfortunately, while Vorlon does pick up my auth landing page as a client, and sees the Office interfaces, none of my console outputs are presented, making it seem as though the JS isn't running at all.
At this point I'm not sure what to try next. Has anyone run into this issue, or gotten this to work on the Outlook 2016 for Mac client?
Clarifying context:
All auth pages are listed in the AppDomains section of the Manifest.
While initial versions pointed directly at our auth service (this worked on not Mac), the current version first opens up an in scope pre-auth page that redirects to the auth service.
The Office-JS api's block alerts, preventing their use in displaying useful information.
Authentication through all versions of this app have worked on both Outlook 2016 on Windows and OWA on both Win and Mac.
Thank you.
This issue in Outlook Mac has been fixed a few months ago. If anyone still encounters this issue with a recent Outlook Mac build, please reply with the build number.
The Office.context.ui is undefined in v16.17 (180909) build of Outlook for Mac 2016 using the following OfficeJS dist:
https://appsforoffice.microsoft.com/lib/1/hosted/office.js
I've got a Word add-in working well on Windows, and the basics are working on Mac also (Word 2016 both).
What browser does Word 2016 for Mac use?
I see this post:
What browser / browser engine do Office Add-ins use?
But it doesn't explicitly define the way Mac does it.
I see posts about clearing the cache, which is helpful (that will be my next challenge) like How to clear client side browser cache for Excel 2016 Task Pane add-in on Mac?.
Specific reason I'm asking is trying to use Firebase for authentication. On Windows, because Word 2016 uses IE11, clicking Login (with Firebase running the show) in my taskpane pops open IE11...and the login through the full browser is recognized by the Taskpane.
On Mac, clicking Login is opening my default browser...
Alternately I could try to keep the Firebase flow in the Taskpane...but not sure how to do that:)
Mostly curious how Microsoft is kludging this on Mac.
For Mac, the native WebKit control is being used (https://developer.apple.com/reference/webkit/webview). Window.open or other popups will open in the default browser and not share cookies or have window.opener pointer to the WebKit control by default. This does not work in authentication scenarios. If you want the popup window to be opened in a separate WebKit control for authentication, you will need to include the trusted domain in the AppDomain list of the manifest: https://dev.office.com/reference/add-ins/manifest/appdomains. window.opener and cookies should then work between the popup and add-in. The AppDomain list is supported on every platform.
When a user goes to my unlisted marketplace app page and installs my app the authorization popup window just white screens and doesn't close. If I manually close the popup everything moves on like normal. I have a suspicion that it's because my app is unlisted, since I haven't seen the issue with other marketplace apps, but as of right now I can't change that.
Another issue we've had with that page is the Integrate with Google button doesn't seem to respect the current profile the user is using. It always seems to always use the default profile which can be confusing for the user if they wanted to use a different google profile they were currently using.
note: the app url i've posted is used for local development but it happens on our production app as well