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.
Conditionally load Add-in on document load
Right now with our PowerPoint office add-in we are loading the add-in during document open time using office.addin.setStartupBehavior(Office.StartupBehavior.load). For the users who already have the add-in, the experience is great when they open the document. But, for others who don't have the add-in they are getting an error popup "This add-in is no longer available: ..." when they open the document that is saved with the office add-in. Can you add some behavior to conditionally load the add-in in the document only if the user has it.Support for Right-Click Event Hook in Word to Dynamically Update Custom Context Menu Items
The Office JavaScript API currently provides support for adding custom items to Word’s context menu and controlling their enabled/disabled state. However, there is no event hook available to detect when a user performs a right-click within the document. This limitation prevents add-ins from dynamically evaluating the current context and updating menu item availability accordingly. As a result, users may encounter disabled options when they expect functionality, or enabled options that are irrelevant to their current selection or location in the document. In contrast, this capability is fully supported in the VSTO (Visual Studio Tools for Office) framework, allowing developers to align closely with Word’s native UX behavior. The absence of a comparable feature in Office JS presents a significant obstacle in the process of migrating existing solutions to the web-based platform. Request: We propose the introduction of a right-click (or context menu) event hook in the Office JS API for Word. This event should provide sufficient contextual information to enable add-ins to make real-time decisions about which menu items should be active. This enhancement would greatly improve the interactivity and responsiveness of modern Office add-ins, helping to bring them closer to parity with legacy solutions and ensuring a smoother user experience.
Control focus and scroll in Word office JS add-in's
Suggestion: Ability to Control Scrolling Behavior in Word JavaScript API Problem: Currently, using Range.select() in the Word JavaScript API automatically scrolls the document to bring the selected range into view. This behavior cannot be controlled or disabled. In many real-world scenarios, this is problematic. Our users often work with large Word documents and long ranges or selections. Any programmatic selection — for example, when updating or analyzing a range — causes Word to jump to another part of the document. This disrupts the user’s workflow and creates a frustrating experience. Proposed Improvement: Add an option to control scrolling behavior when selecting or manipulating ranges. For example: range.select({ scroll: false }); This would allow developers to programmatically select or update ranges without forcing Word to scroll to that location. Impact: Providing control over scrolling would greatly improve usability for scenarios involving background processing, automated edits, or analytical operations in large documents, where visual focus should remain undisturbed
Customize default task pane width for Excel add-ins
The default width of the task pane in Office add-ins is quite small, making styling difficult when you want to display more content in it. At a 1366x768 resolution, for Excel desktop the width of the task pane is 320 pixels. It would be nice if we could customize the default width of the task pane from the manifest or via the Office JS API.
Office.js API — Open OneDrive Files in Current Word/PPT Instance
Currently, Office.js does not provide an API to directly open a OneDrive (or SharePoint Online) file in the current Word/PPT desktop instance. For add-ins that integrate with external systems, this creates a significant limitation. Users often need to: Access Word/PPT documents stored in OneDrive/SharePoint directly from an add-in. Ensure the file opens seamlessly in the same Word/PPT session, without forcing them to manually download or open a new instance. Why this is important Improves user workflow and productivity. Essential for add-ins that sync or integrate with cloud storage and external systems. Avoids user confusion from multiple Word windows or manual file handling. Requested capability An Office.js API such as: Office.context.document.openFileFromUrl(fileUrl, options); where fileUrl is a OneDrive/SharePoint URL and options could specify whether to open in the current instance or a new one. This would align Office.js capabilities more closely with real-world workflows and reduce friction for both developers and end-users.
