Classic Outlook for Windows - LaunchEvent functionality completely broken

[pepso]

Provide required information needed to triage your issue

Developing Classic Outlook Add In with LaunchEvents is a major headache as there's no logs, no guidance, nor information what is going wrong within the environment. We have spent now weeks to investigate how to get our Add In to work in Classic Outlook without any luck. Here's a simplest reproducible example what we can come up with:

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC Desktop
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: Microsoft® Outlook® for Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) 64-bit
• Operating System: Windows 11

Expected behavior

We expect LaunchEvents to work when Outlook Add In project is generated with yo office generator and by following steps from launch event tutorial.

Also expectation is that there is some way to troubleshoot and get information on why things don't work as the classic Outlook runtime for launch events is silent black box. Currently there is no option to debug or log as there is no process to attach to prior to code execution.

Current behavior

When a new Task Pane Add-In project is generated using "yo office", which then is updated with launchevent example "Automatically set the subject of new message or appointment" from https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/on-new-compose-events-walkthrough?tabs=xmlmanifest, then this causes the Add In to stop working.

Before the launch event is fired for first time, Contoso taskpane opens ok (but "Loading..." is overlayed on it) and ribbon button performs an action just as expected. When you try to compose a message or appointment (first launch event), all goes to bonkers. Taskpane takes 60 seconds to load and this same applies to built in Add Ins like "Send to Onenote".

Based on runtime logs, a resource cannot be loaded when the launch event is triggered first time however manifest and bundle is available in the Wef folder as expected.

Steps to reproduce

1. use yo office to generate "Office Add-in Task Pane project" with following options
   • ? Choose a project type: Office Add-in Task Pane project
   • ? Choose a script type: JavaScript
   • ? What do you want to name your add-in? brokenAddIn
   • ? Which Office client application would you like to support? Outlook
   • ? Which manifest type would you like to use? XML manifest
2. Add the changes from https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/on-new-compose-events-walkthrough?tabs=xmlmanifest

• update manifest.xml with version override section
• create launchevent/launchevent.js,
• update the commands.html
• update the webpack config
• npm run build
• npm start

3. Select an email from inbox and "Show Taskpane"
4. Perform an action from the ribbon
5. Compose "New Email" and see no subject is being set
6. Close the email or leave it open and go back to inbox to open taskpane or perform an action and everything hangs for 60 seconds

Obviously there's the other issues with Add In ribbon availability issues across the clients and they appear and disappear across the clients over time.

Context

Our clients want to use AddIn on Old outlook, OWA, new outlook, and outlook on mac while ~60% are on classic outlook which makes this a major headache. Most of our clients are not ready to upgrade to new Outlook at least in the coming year because of the Add In ecosystem issues so the support for Old Outlook is required for foreseeable future.

Our Add In itself works well across all other Outlook versions except Classic Outlook, and this issue is based on simplest example we can come up with what is broken.

It's frustrating not to get any input on same or similar issue reported already in October/November 2023: https://github.com/OfficeDev/office-js/issues/3758

Are LaunchEvents supported still in classic Outlook? Is this issue development environment related? Any guidance would be highly appreciated.

Useful logs

Office Add In log lists this when the first event is being fired: Unexpected Resource The resource you are trying to use does not exist.

bundle.js loaded fine to Outlook cache folder so the resource access error seems odd:

No issues when generating the Task Pane project:

Taskpane with "Loading..." overlay:

Taskpane "loading..." for 60 seconds after the first launch event is triggered:

Performing an action from ribbon "brokendAddIn is working on your Perform an action request." for 60 seconds until it actually works:

Even Send to OneNote hangs for 60 seconds:

Add In is available with hit and miss style and usually within 24h it gets available more or less in uniform way across the clients:

Any somewhat relevant errors/issues in Event Viewer are coming from Microsoft's "Meeting Insights":

I have thus far tried to uninstall office, and reinstall it but the problem still continues. Cleanin up cache(s), registry, or any other logical attempt has not yielded any consistent behavior to fix any of the issues experienced with Classic Outlook Development Environment issues.

Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.

[pepso]

I also decided to attempt another tutorial to make sure it's not just issue with tutorial documentation, but something with Classic Outlook. This time I completed and used code from "Automatically check for an attachment before a message is sent": https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/smart-alerts-onmessagesend-walkthrough?tabs=xmlmanifest

I can confirm the broken behavior of the Classic Outlook is 100% the same with this tutorial as well.

[timwan10]

Debugging Launch Events on Classic Win32, isn't great right now, and things are being worked on to improve it. Usually the underlying issue, is that launchEvents are run in a JS runtime on Classic Outlook, and in a WebView in the other platforms. The runtime doesn't support a lot of stuff in normal javascript. Which usually results in one of two errors:

• Runtime Error -> Results in an uncaught exception thrown, and causes the launchevent to not call Event.completed, and it just kind of sits there until it times out

• Compile Time Error -> Launch event doesn't work, but it's really hard to track down where this error is.

To find the error I usually do the following to catch the Runtime Errors:

Set up the DirectDebugger Registry: (see screenshot) Replace the GUID with your Add-in Id. (you likely don't need the DebuggerPort Entry)

If this is done correctly you should see this Dialog box pop up when the Launch Event is running:

While this dialog is up. Navigate Edge. (Edge should be the new Chromium edge, not "Spartan Edge")

edge://inspect

Under Remote Target you should see the Add-in there. It can take some number of seconds for it to show up. (sometimes I hit F5 to refresh...but it still takes some time for it to come through) If this doesn't show up eventually you can try messing with the DebuggerPort registry entry from the screenshot, and matching the port # in the Edge Debugger.

Once you have this set up. It's a standard JS debugger. You can open up the sources/console and put breakpoints in your files, and step through things. Hit Ok on the dialog that Outlook popped up to start debugging.

The official documentation for the above is here: https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/debug-autolaunch?tabs=windows

If you never even reach that, then there is likely some sort of syntax problem with your bundle. (and it can be something lame that isn't ECMAScript 2016 compatible, like async and await)

Even you can't reach even that point:

Try turning on rutime logging (not the windows event log) here: https://learn.microsoft.com/en-us/office/dev/add-ins/testing/runtime-logging

Namely add the registry entry:

This should log issues with getting the JS Runtime Sandbox started.

If done correctly this should log some errors to file that you specify here, and may give some more insights.

Note that Runtime Logging incurs a performance hit, so if you set it up on a client machine, or your regular machine, make sure to turn it off when you're done with it.

Barring that, you can upload the contents of your bundle.js and the manifest.xml here and someone can take a look.

[pepso]

Hi @timwan10 and thanks for the reply.

Indeed I have runtime logging turned on, and also know how to attach process to the debugger if I just would ever get thus far.

This is indeed the dialog I hope to see on my localhost:

In the past couple of days I have found out following with the posted example and then our actual Add In:

1. Our actual add-in installed through https://admin.microsoft.com/AdminPortal/Home#/Settings/IntegratedApps was failing on simple JS execution on runtime Intl.NumberFormat on maximumFractionDigits:0 (trident vs edge chromium parameters differ)
2. Execution of launch events only takes place when I deploy our actual add-in (or the example code in this issue) through the admin portal
3. This leads me to believe LaunchEvent's are not firing on localhost at all as the complete same budle.js is executing fine on dev and in production (when deployed through admin portal), but not when sideloaded and hosted on localhost.

Currently this leaves me to an absurd "development flow" which I used to find the above maximumFractionDigit bug:

• Develop code and hope one can guess the trident runtime differences vs. edge chromium
• Push the code to a branch and get it bundled and prepped through the CI/CD pipeline
• Update the add-in through admin portal with custom manifest
• Wait anywhere between 2-24h until add-in manifest version is the latest deployed to classic outlook
• And then finally I actually see runtime logs and add in being firing the LaunchEvents

I tested the same thing with the yo office generated example and oh dear the launch events started to fire after I deployed the add in via admin portal.

Obviously this leaves me unable to debug/test the add-in on localhost so this is not sustainable to develop any features (classic Office JS runtime does require branching of code base due to local storage and few other reasons) which is deeply troubling.

Somehow I'm having a hunch the culprit for this issues revolves around feature described here: https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/autolaunch#deploy-manifest-updates

Basically I have few leading questions: Is there a way to make add-in on localhost to be trusted/authorized so it will fire launchevents? Is there some setting in admin portal or local registry change I can do to avoid this? Is it possible to add admin consent for localhost add-ins through the admin portal?

[pepso]

Meanwhile I typed my comment it made me think and now I have a bit "easier" local development flow which I just confirmed:

• Develop on localhost and guess what you are supposed to do (using taskpane's runtime, console, and debug options)
• Build the project (or rely on HotUpdates) to get the polyfilled dist codebase for sideloaded add-in
• Copy the bundle.js code (from localhost manifest's Wef Javascript cache folder) to the admin portal deployed add-in's cache folder
• Close and open the current runtime (i.e. close open appointment and open it again) so Outlook 'reloads' the localhost bundle.js from cache for execution

I guess this proves my bundle.js code is not the culprit as it works as long as the manifest is deployed through the admin portal instead of sideloaded. Only thing missing with the localhost add-in is the firing of launch events.

[timwan10]

I can double check with some developers about the Localhost thing, but I believe that is supposed to work. LaunchEvents currently do NOT work via Add-ins installed via the Store (unless by Admin) but that doesn't sound like what you are doing here? How are you installing the manifest for the localhost add-in? (please be specific here, as the method of installing the add-in, can affect if launch events work). It should work if the Localhost add-in is sideloaded.

Modifying the bundle.js in the WEF folder DOES work, and is a reasonable solution for "quickly modifying and testing changes." However, it can be replaced on Outlook boot. (Outlook may download and replace the file in the cache, depending on cache-expiry/updates on server/etc.) So don't save vital changes in ONLY that file, as they may get rewritten at some point.

[pepso]

Hi @timwan10,

Thanks for the reply.

I am attempting to sideload the extension under development using this command from the yo office generated command (here's the console output for the command output):

npm start:

> office-addin-taskpane-js@0.0.1 start
> office-addin-debugging start manifest.xml
Debugging is being started...
App type: desktop
Enabled debugging for add-in f2da3848-bf7c-404f-83f6-e55f250080e2.
Starting the dev server... (webpack serve --mode development)
The dev server is running on port 3000. Process id: 22892
Sideloading the Office Add-in...
running: npx @microsoft/teamsapp-cli install --xml-path "C:\add-in-folder-path\brokenAddIn\manifest.xml"

This command is in preview.
Using account xxxx
TitleId: U_27738cb7-ee5d-d0e9-f3be-c75a066eee22
AppId: f2da3848-bf7c-404f-83f6-e55f250080e2
Sideloading done.

Successfully registered package! (U_27738cb7-ee5d-d0e9-f3be-c75a066eee22)
 STDERR:

Launching outlook via C:\Program Files\Microsoft Office\Root\Office16\OUTLOOK.EXE
Debugging started.

I have tried to load the extension manifest through the Classic outlook's "Manage Add-ins" button which takes you to this screen:

Either way I get the same result (no launch events).

The issue with my current development flow (without functioning localhost launchevents) is that there is no way to attach to the debugger when developing the add in. This then results to a lot of trial and error to understand what happens on the trident's JS Runtime vs. chromium/vebview2 based JS runtime.

[timwan10]

hearing back from the devs, this is supposed to work. (loading from Localhost) There were some issues with this on Windows 10...but you mention that you are loading from Windows 11. Apparently there were some bug fixes to the runtime for the version after this. Is it possible you could check this again on a later version of outlook? I believe the latest version available in production is 16.0.17531.XXXXX

If you are on the insiders' program you should have even later builds (17628)

[pepso]

Hi @timwan10 ,

Currently I'm on: Microsoft® Outlook® for Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) 64-bit.

Here's my windows info: Edition Windows 11 Pro Version 23H2 OS build 22631.3447

I have had multiple versions of the Outlook since I first time experienced this issue in latter part of 2023. None of the versions I had between 2310 to current 2403 fired the launch events. I don't have records what builds I have had in between these two.

It was only now when I exhausted all the options by myself unable to get the events working when I raised this issue.

Here's a link to the comment I made back then when I first time observed the issue. Back then I was using the same build as the person raising the issue: Version 2309 which I updated to 2310.

Since my comments in the issue from end of last year I have updated all the relevant npm packages and I noticed the new way of sideloading using teamsapp-cli since then. Even with the npm package updates nothing changed (launch events not firing).

I'm working on something else this week so won't be able to test the latest version right now but I'm fairly certain this issue is something quite fundamental as the builds between 2309 -> 2403 have resulted in same lack of events being fired.