Word JS API - Simple events for content controls
Subscribing to events on content controls in large documents with many instances are not optimal. It is pretty bad that it is necessary to register events on every single content control. Please add new events on the document level. For example: context.document.onContentControlUpdated context.document.onContentControlDeleted context.document.onContentControlEntered context.document.onContentControlExited Let us just subscribe to these and get the event on all content controls in the document. Much simpler and more effecient The existing event context.document.onContentControlAdded works very well. Also, remember to trigger the onContentControlUpdated event on any change to the contents and/or metadata.
Improving Excel Add-in API failures when in CellEditMode
Hello Microsoft Add-in team! I'm developing an Excel Add-In and have some suggestions relating to Excel.ErrorCodes.invalidOperationInCellEditMode. I'm finding that having the Excel Add-In APIs all either delay execution or throw the CellEditMode error while the user is in cell edit mode is making for a bad user experience in my Add-in. For example, at launch, my Add-In TaskPane needs to check the workbook CustomXML for metadata specific to my Add-In. But (if I'm not mistaken) I can't do that if the user is in cell edit mode. It seems I have to call the API, get a failure, then tell the user something like "The Add-In is waiting for you to finish editing your cell" and try again with { delayForCellEdit: true }. It's messy. So my suggestions are three, supposing CellEdit errors are in some cases necessary: 1.) Can we make it so that not *every* API call is blocked when in CellEdit mode? For example, why should reading/writing CustomXML be blocked because of cell editing? Is the error being thrown unnecessarily in some cases? 2.) Can we add a new "addHandlerAsync" event for CellEditMode enter/exit, to allow a TaskPane to disable buttons that aren't going to work while the user is in CellEdit mode? Disabling such buttons (with explanation, of course) could make for a better TaskPane user experience than having the user clicking a button and getting an error. (I do realize the error could still happen, as change events seem to fire on a delay, but they might at least happen less frequently!) (For example, in my Word Add-In, I am enabling/disabling buttons based on user's content selection, and the experience seems to be nice, even with the slight delay.) 3.) Can we add another callback param to "Excel.run({ delayForCellEdit: true }, ...)" so the developer can know that their API calls will be delayed and the user can be prompted to exit CellEditMode? (That might clean up me having to try, catch and then retry with delay?) I'm sure you've thought about all this more than I have, but these are the issues I'm running into. Thanks for your time and keep up the good work!
Ability to Assign Custom Properties or Unique IDs to Individual Cells
Summary I'd like to request support for assigning custom metadata — such as unique IDs or arbitrary key-value pairs — directly to individual cells in Excel using the Office.js API. Why This Matters Currently, developers must rely on workarounds like named ranges, hidden metadata sheets, or cell notes to simulate per-cell identifiers. These approaches are either limited, fragile, or not scalable for large applications. Native support for cell-level metadata would unlock powerful use cases: Dynamic form builders Cell-level validation engines Workflow tracking Data lineage and audit trails Integration with external systems via stable cell references Proposed API Concept range.customProperties.add("id", "cell_001"); const id = range.customProperties.getItem("id").value; Or even: range.metadata = { id: "cell_001", status: "approved", validator: "admin" }; Benefits Eliminates reliance on fragile naming conventions Enables scalable, structured metadata management Improves developer experience and app robustness Alternatives Considered Named ranges: limited and global scope Notes/comments: visible to users, not structured Hidden metadata sheets: hard to maintain Custom XML parts: complex and not cell-specific Request Please consider adding support for cell-level metadata or custom properties in a future version of Office.js. Even a lightweight key-value store per cell would be a game-changer.
Retrieve the existing contents of a cell that invokes a function
Define the problem My Excel add-in has custom functions which call external APIs. These API calls are invoking complex models running in the cloud which can sometimes take minutes to complete and therefore return data to Excel. My users build large workbooks with potentially thousands of these functions. Often the user makes a change in their workbook which triggers all of these calculations again even though there's no change in the input data. An example would be insertion of a row or column. This causes huge pain for the end user. Solution Microsoft to update the Office JS API so that when a function is invoked it can check the contents of the cell that invoked the function. I seem to remember this was possible in the old COM add-ins but it's not possible in the Office JS add-ins. Why does this help My custom functions store both the API request and response in the data card (Excel.EntityCellValue) format. Since I effectively store the original API request in the cell, if the cell gets inadvertently invoked I can check the arguments of the functions (the input data) against the original API request and if nothing has changed then I can return the original API response stored in the cell. This is like cancelling a function but being able to return the original data rather than anything new. Alternatives I can implement caching, e.g. using IndexedDB, but that's not the ideal solution. The ideal is the above.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.Feature Request: Add error/rejection support to Office.onReady() for network/dependency failures
Description Currently, when Office.js loads but one of its dependent resources (such as office_strings.js) fails to load due to network issues or blocking, the Office.onReady() promise never resolves or rejects. This leaves developers without a reliable way to detect missing dependencies. Instead of relying on timeouts or log messages, it would be very helpful if Office.onReady() provided an error callback or rejection in these scenarios. Why this matters: Helps developers handle production failures gracefully. Avoids arbitrary timeouts/workarounds to detect missing dependencies. Provides parity with modern async practices where promises resolve or reject deterministically. Enables better telemetry/analytics by explicitly knowing why initialization failed. Suggested Approach: If a required dependency fails to load, Office.onReady() should reject with an error describing the missing dependency. Alternatively, provide an event/callback (e.g., Office.onError) that developers can subscribe to. Example: Office.onReady() .then(info => { console.log("Office.js initialized:", info); }) .catch(err => { console.error("Office.js failed to initialize:", err); // custom fallback handling }); Impact: This would improve developer experience significantly and make add-ins more resilient in real-world network environments.Add viewportChanged event to Word JavaScript API
In Word add-ins, we often need to react to changes in the user's viewport (scrolling, zooming, etc.). Currently, there's no event to detect when the visible pages change. A viewportChanged event on Word.Pane or Word.Window would allow developers to optimize performance and create dynamic experiences based on what the user is viewing.
