Office.js API Request: Context-Anchored Sandboxed Web Surfaces for Excel, Word, and PowerPoint
Office Add-ins currently provide cross-platform task panes, dialogs, and add-in commands. However, developers cannot display sandboxed and interactive web content anchored to a selected document object without inserting a native shape, image, text box, content control, or other persistent Office object. I propose a cross-platform Context-Anchored Web Surface API for Excel, Word, and PowerPoint. The API should allow an Office Add-in to attach a sandboxed web card to the current selection or to a supported document object, including: Excel ranges, table cells, charts, images, or shapes Word text ranges, paragraphs, table cells, images, or content controls PowerPoint text ranges, shapes, images, table cells, or slides The surface should not become part of the native document drawing layer unless the developer explicitly requests conversion to a document object. Office should manage: Position relative to the anchor Focus and keyboard interaction Security boundaries Z-order and clipping Scrolling and zoom behavior Word document reflow PowerPoint editing and presentation modes Surface lifetime and restoration Cross-platform behavior The proposed API should provide: A unified cross-host anchor abstraction Persistent anchor identifiers Selection, session, document, and manual lifetime modes Preview, interactive, and editor interaction modes Sandboxed iframe or WebView content Automatic viewport-aware placement Host-managed repositioning during scrolling, zooming, layout changes, or document reflow Explicit print, PDF export, image export, and presentation rendering policies Message passing between the Office Add-in runtime and the contextual surface Requirement-set detection across Windows, macOS, Office on the web, and supported mobile clients An example API could look like: Office.context.ui.contextualSurfaces.create({ anchor: Office.context.document.getSelectionAnchor(), source: { url: “https://example.com/context-card” }, placement: { preferred: “right”, keepInViewport: true, followAnchor: true }, interaction: { mode: “interactive”, dismissOnEscape: true }, lifetime: { mode: “document”, restoreOnOpen: true }, rendering: { mode: “authoringOnly”, includeInPrint: false, includeInExport: false } }); This would enable contextual experiences such as: Chemical compound and molecular structure cards Biomedical annotations Citation and literature tools Translation and terminology previews Financial and company data cards Educational explanations AI-assisted review tools Domain-specific document annotations Today, developers must choose between a fixed task pane and native document objects. A host-managed contextual web surface would provide a secure and consistent middle layer while preserving document integrity and cross-platform compatibility.
Support custom functions downstream of iterative (circular) calculation - currently return #CALC!
Office.js custom functions in Excel return #CALC! whenever any of their precedents involve a circular reference chain resolved by iterative calculation, even when the function itself is not part of the loop. (Tracked in https://github.com/OfficeDev/office-js/issues/4738, open since July 2024.) Many common financial usecases require iterative calculations as part of standard practices. As an example, average-balance interest with iterative calculation is the mainstream convention in leveraged-finance modeling. Interest expense depends on the average debt balance, which depends on cash paydown, which depends on interest expense. Analysts across banking and private equity resolve this loop with Excel's iterative calculation setting. The same pattern appears in revolver/cash-sweep modeling and fund fee/NAV calculations. These workbooks worked for decades with XLL and VBA UDFs. Any custom function consuming a model's outputs (e.g. an add-in function that writes results back to an external platform) is by definition downstream of the circular chain, so it always fails in these models. We've verified: a custom function with literal arguments works; the same function with an argument fed from the converged loop returns #CALC!; severing the dependency with IF(TRUE, value, FN(...)) makes it work again. This blocks migration from legacy XLL/VBA add-ins to the modern Custom Functions API for financial-modeling users. The ask: custom functions downstream of a circular chain should evaluate against the loop's converged values after the iteration pass completes — matching legacy XLL/VBA UDF behavior. Custom functions don't need to participate in the iteration itself.
Show "Loading add-in" before the task pane web app is available
Product Office.js / Outlook Classic (Task Pane Add-ins) Problem Description When a task pane add-in is opened in Outlook Classic, there can be a significant delay before the add-in's web application is displayed. During this phase, users often see a blank or empty task pane without any indication that the add-in is still loading. Based on our observations, this delay frequently occurs before the add-in page itself is loaded and before any JavaScript code can be executed. The startup time appears to be heavily influenced by the underlying Chromium/WebView network initialization and page-loading process. As add-in developers, we currently have no opportunity to provide feedback to the user during this early loading phase because the web application has not yet started executing. User Impact A blank task pane creates the impression that: Outlook has frozen. The add-in has crashed. The add-in failed to load. The user needs to close and reopen the add-in. This leads to confusion, unnecessary support requests, and a poor user experience, especially in environments with slow network conditions, security software, proxy servers, or delayed WebView initialization. Proposed Enhancement Provide a native Outlook-hosted loading screen that is displayed immediately when the task pane is opened and remains visible until the add-in page has started loading successfully. Example messages: "Preparing add-in..." "Loading add-in..." "Initializing add-in environment..." The loading screen could optionally include: A progress indicator or spinner. Diagnostic information for troubleshooting. A timeout message if loading exceeds a configurable threshold. Alternative Proposal Expose an API that allows developers to define static HTML content that Outlook can display before the actual add-in page is loaded. Since displaying simple HTML content is possible without waiting for the complete network stack and WebView page initialization, this would allow developers to provide immediate visual feedback while the Chromium/WebView infrastructure is still preparing the add-in. Benefits Improved user experience. Reduced perception of application hangs. Fewer support tickets related to slow add-in startup. Better transparency during WebView initialization. Improved reliability perception for Office Add-ins in enterprise environments. Environment Outlook Classic for Windows Office.js Task Pane Add-ins Chromium-based WebView runtime The issue is most noticeable in environments where WebView initialization or network-related startup operations are delayed.
No programmatic way to pin the task pane for users
Your Environment Platform: PC desktop, Mac, Office on the web Host: Outlook Office version number: All supported versions Operating System: Windows, macOS Expected behavior The Office JS API should provide a programmatic mechanism to pin the task pane on behalf of the user — for example, via a manifest setting or a runtime API call — so that the task pane remains open and pinned without requiring manual action from each user. Current behavior There is no programmatic way to pin the task pane for users. Users must pin it manually via the UI. This results in an inconsistent experience, particularly for enterprise deployments where we need to ensure the add-in remains accessible without relying on individual user action. Context We need the task pane to remain pinned for all users automatically upon install or first launch. The current lack of a programmatic pin mechanism creates friction and support overhead, as users frequently close the task pane and do not know how to re-pin it. We are looking for either an existing API we may have missed, or confirmation that this is a platform gap so we can raise a feature request through the appropriate channel.
Gracefully handle unavailability of Office.js
The reliance on Office.js (and its dependencies) delivered from the network proves to be challenging in some scenarios. While ideally the platform would support full offline use, I'm hopeful that there are some incremental improvements that could be made to address some of our challenges in the shorter term. As an example, our add-in hooks into Outlook's OnMessageSend, which inherently puts it on the critical path of the user experience when sending emails. In scenarios where the user's network is slow or unreliable, or in an event of an Azure CDN outage that makes Office.js unavailable or slow to be delivered, the user experiences a long wait while Office.js is loaded on message send. I should highlight that Outlook attributes this delay to the add-in: "Add-in X is taking longer than expected". I'd like to propose that the platform gives the add-in more control over the user experience in these cases. What this would look like for our OnMessageSend add-in is that the add-in would execute some code outside of the event handler (before Office.js finishes loading) to start a timer, and if the loading phase exceeds a timeout value defined in the add-in code then the add-in would instruct Outlook to conclude the processing of the event (similarly to how event.completed() is invoked inside an event handler). That last part would require some interface with Outlook that is available even if Office.js hasn't been fully loaded.Feature Request for Enhanced Outlook Add-in Surfaces
Feature Request for Enhanced Outlook Add-in Surfaces Request Title: Expandable/Pop-out Outlook Add-ins with Inline Compose/Reply Integration Products/Platforms: Microsoft Outlook Add-ins (Office.js) across Classic Outlook for Windows, New Outlook for Windows, Outlook for Mac, and Outlook on the web (OWA) Request Type: New extensibility capabilities / UI host surfaces for Outlook add-ins Priority: High (end-user productivity + adoption + enterprise usability) Background We use an Outlook add-in to integrate additional productivity tools into the email workflow to help users save time, reduce context switching, and improve execution quality. This is a core enablement pattern for enterprise users who spend significant time in Outlook. Today, our add-in runs primarily in the task pane, which has notable limitations in flexibility and available space. The current experience is increasingly cluttered and not user-friendly, especially for workflows that require richer UI, multiple steps, or contextual data. Additionally, the add-in is not seamlessly integrated into the new message compose and reply experience (i.e., the workflow is not inline with the compose/reply window), which limits usability for scenarios that must occur at the moment a user is authoring a message. Problem Statement Current task pane constraints lead to: Limited UI real estate (narrow layout, heavy scrolling, cramped forms, poor readability) No user-friendly expand/enlarge options to fit different workflows and screen sizes Reduced usability during compose/reply, where users need the tool inline with message authoring Lower adoption and productivity because the add-in experience feels disconnected and cumbersome In practice, users need more space and tighter integration at the exact point of work (compose/reply), without leaving Outlook or juggling multiple windows. Requested Features We request Microsoft to support the following add-in UI capabilities, ideally consistently across Classic Windows, New Outlook, and OWA: A) Expandable / Resizable Task Pane Allow users to resize/expand the add-in pane (wider layout; optional full-height behavior) Support a compact vs expanded mode with user preference persistence Outcome: Richer workflows become usable without redesigning into cramped layouts. B) Pop-out Add-in Experience Provide a supported pop-out window for the add-in (while maintaining context to the current item) Ensure pop-out works smoothly with enterprise policies and does not break the add-in lifecycle Outcome: Users can work with complex UI without sacrificing mail reading/authoring space. C) Inline Add-in Integration with Compose and Reply Enable add-in UI to appear inline within the compose/reply window (not just as a separate side pane) Support contextual actions/data entry during authoring (e.g., insert content, validate, attach artifacts, update records) Ensure consistent behavior for new compose and reply experiences Outcome: The tool is available at the moment users need it while writing responses, driving adoption and reducing errors. D) Add-in as a Mail Tab Provide a supported extension point for an add-in to appear as a tab in Mail, similar to “Focused/Other” Tab hosts a larger workspace for add-in workflows (e.g., triage/queue/workbench views) Outcome: A first-class workspace in Mail for workflows that don’t fit the task pane model. Key Enterprise Use Cases Multi-step workflows triggered from emails (triage, intake, approvals, routing) Rich forms and guided actions that are impractical in a narrow pane Compose/reply-time actions: insert approved templates/snippets, validate recipients/content, capture metadata, create/update tasks/records Dedicated mail workbench views via a tab for operational roles Acceptance Criteria Cross-client consistency: Classic Windows, New Outlook, and OWA supported with minimal divergence Next Steps for Microsoft Confirm roadmap/feasibility for: expandable task pane, add-in pop-out, inline compose/reply surface, and mail tab surface Provide recommended implementation model/APIs and opportunities for preview/early access for enterprise validation Screenshots for Reference
Add a Range API for Outlook add-ins
Word add-ins provide the Word.Range API, which allows precise manipulation of document content (selection, insertion, replacement, formatting). Outlook add-ins currently lack an equivalent API, making fine-grained interaction with the message body difficult or impossible. We propose adding a Range-like API for Outlook add-ins to enable: • Access to the current selection in the message body • Insert or replace text at a specific position This would significantly improve advanced authoring, productivity, and AI-assisted scenarios in Outlook. Example (conceptual) const range = Outlook.context.mailbox.item.getSelectedRange(); range.insertText("Hello world", Outlook.InsertLocation.replace); Reference Word Range API : https://learn.microsoft.com/en-us/javascript/api/word/word.range?view=word-js-previewOffice Addin - First Letter Navigation in menus
Some UI components, such as dropdow lists, do support first letter navigation, i.e. lets the user navigate through the items of a list based on the first letter of the item's title. Here is a concreate example: In Word, go to File > Options > General > Office Background > Down arrow (to open the dropdown list). In here, if I press 'C' once, I land on 'Calligraphy'. If I press 'S' once, I land on 'School Supplies', press 'S' a second time I land on 'Spring', press 'S' a third time I land on 'Starts', and so forth. However, such navigation mechanism is not supported for menu components. For example: In Word, go to Insert > Link > Recent items. I have a long list of recently accessed Word of Excel documents (let's call them Document_1, Document_2, ..., Document_n). When I press 'D', I get an error beep and nothing happens. Indeed some items are linked to a keytip, but I cannot navigate the list as described above. We are developing some VSTO add-ins for Excel, Outlook, Powerpoint and Word for visually-impaired users. For each, we are creating a simplified ribbon that provides them with a subset of functionalities. For example: <?xml version="1.0" encoding="UTF-8"?> <customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="Ribbon_Load"> <ribbon startFromScratch="true"> <tabs> <tab id="MainMenu" getLabel="GetMenuLabel" visible="true" keytip="M"> <group id="FunctionsGroup" getLabel="GetGroupLabel"> <menu id="FileFunctions" keytip="F" getLabel="GetMenuLabel" > <!--Action_1--> <button id="Action_1" getLabel="GetButtonLabel" getImage="GetButtonImage" getScreentip="GetScreenTip" getSupertip="GetSuperTip" onAction="OnActionButton" /> <!--Action_2--> <button id="Action_2" getLabel="GetButtonLabel" getImage="GetButtonImage" getScreentip="GetScreenTip" getSupertip="GetSuperTip" onAction="OnActionButton" /> <!--Action_N--> <button id="Action_N" getLabel="GetButtonLabel" getImage="GetButtonImage" getScreentip="GetScreenTip" getSupertip="GetSuperTip" onAction="OnActionButton" /> .......... </menu> </group> </tab> </tabs> </ribbon> </customUI> Having first letter navigation work in menus would be a major gain in terms of accessibility throughout all available Office menus (which there are hundreds and more shared between all Office apps). My questions: Are there plans to support first letter navigation for menu components? Is there a way we can attach key event handlers to UI components such as menus that are created from a ribbon.xml file?
Add an OptionPane for add-ins preferences
In each Office Settings... having a add-ins section where all installed add-ins with a declared OptionPane would appear. Selecting the OptionPane would display it aside the list of add-ins with the one being displayed highlighted. In the OptionsPane, the add-ins would be able to have an interface to configure its parameters (For example, for a Zip based add-ins, the user would be able to set the compression method or the default compression level). Another example:for a filtering add-ins, you could select which mailbox or which folder it applies to. The declaration in manifest would be similar to TaskPane, but it would be displayed in a different context. TaskPane is a bad place for that and buttons is not a better place either. Settings should be in an unique place: Settings...Support for Split Button in ribbon
We need a way to declare a split button (an action button with a drop down menu accessible by clicking the down arrow next to the button. (like. the Flags split menu in Outlook (button can clear the flag while dropdown menu can select a flag). The manifest could be a menu with an ExecuteFunction at the item level. If an execute function is present, the rendering is a Split-Button otherwise it's a classic menu. A example taken from New Outlook for MacOS. The split button exists, but it's unavailable to office.js add-ins.
