Difficulty Detecting Compose Mode on macOS in Office Add-ins

On macOS, detecting compose mode reliably in Office Add-ins has proven challenging due to limitations in Office.context.mailbox.item behavior. Specifically:

Context Limitation: Without using preview permissions, Office.context.mailbox.item doesn’t provide access to the item context, making it impossible to detect if the add-in is in compose or read mode.
Workaround with URLs: To address this, I attempted a workaround by defining two distinct URLs in the manifest, one for compose and another for read. By checking URL query parameters, I can differentiate between compose and read modes in my application. However, this solution only works if ReadWriteItem permissions are used. With ReadWriteMailbox permissions, the detection fails.
Pinned Application Behavior: Additionally, when the application is pinned (e.g., for contextless or multiselection support), switching between compose and read modes requires a full add-in reload (closing and reopening). This requirement to reload affects user experience, as the relevant mode-specific actions in the application may not display correctly without manual intervention.

Impact: The ability to reliably detect compose vs read mode is essential for our use cases, which include showing relevant actions based on the current mode (e.g., different actions for composing a message vs. reading one). The current limitations disrupt the user experience, especially for applications that need to handle multiselection, contextless scenarios, or smooth transitions between compose and read.

Expected Behavior: Ideally, Office.context.mailbox.item should provide mode detection consistently on macOS, regardless of the permissions used, and without requiring an add-in reload when switching between compose and read.

### Steps to Reproduce:

Set up an Office Add-in on macOS.
Attempt to detect compose mode using Office.context.mailbox.item.
Observe that without preview permissions, detection is not possible.
Use a workaround by defining different URLs for compose and read and checking query parameters, noting that it only works with ReadWriteItem and not ReadWriteMailbox.
Pin the add-in and switch between compose and read to observe the need for a full reload for mode detection to take effect.

Your approach with URL's in bullet #2 is the correct way to handle this.

Regarding the pinned application behavior and the app reloading between contexts. Yes, that is by design. They took a different approach to add-ins this time. They are meant to enhance the user experience rather than take complete control like the old COM add-in framework did. Add-ins now load on demand.

Hi There, Seems like the fix you provide is working only if I re-open the addin closed and open. Otherwise, it behaves like the last mode compose or read. You can try it. Step to repo:

Outlook desktop on MAC
Configure Outlook to show new messages inline ( open in the main window)

From: Nicholas Lechnowskyj @.> Sent: Saturday, November 16, 2024 5:25 PM To: OfficeDev/office-js @.> Cc: Amitai Biton @.>; Author @.> Subject: Re: [OfficeDev/office-js] Difficulty Detecting Compose Mode on macOS in Office Add-ins (Issue #5092)

To detect whether your taskpane is operating in the compose or read mode is simple, but you need to infer this from a much higher level.

In the manifest you define event handlers for read and compose and there you can define your taskpane URL with a query string or different path altogether.

      <ExtensionPoint xsi:type="MessageComposeCommandSurface">

        <OfficeTab id="TabDefault">

          <Group id="msgComposeGroup">

            <Label resid="GroupLabel"/>

            <!-- Show Delivery Trust button -->

            <Control xsi:type="Button" id="msgComposeOpenPaneButton">

              <Label resid="TaskpaneButton.Label"/>

              <Supertip>

                <Title resid="TaskpaneButton.Label"/>

                <Description resid="TaskpaneButton.Tooltip"/>

              </Supertip>

              <Icon>

                <bt:Image size="16" resid="Icon.16x16"/>

                <bt:Image size="32" resid="Icon.32x32"/>

                <bt:Image size="80" resid="Icon.80x80"/>

              </Icon>

              <Action xsi:type="ShowTaskpane">

                <SourceLocation resid="Taskpane.Url"/>

                <SupportsPinning>true</SupportsPinning>

              </Action>

            </Control>

          </Group>

        </OfficeTab>

      </ExtensionPoint>

      <!-- On email read -->

      <ExtensionPoint xsi:type="MessageReadCommandSurface">

        <OfficeTab id="TabDefault">

          <Group id="msgReadGroup">

            <Label resid="GroupLabel"/>

            <!-- Show Delivery Trust button -->

            <Control xsi:type="Button" id="msgReadOpenPaneButton">

              <Label resid="TaskpaneButton.Label"/>

              <Supertip>

                <Title resid="TaskpaneButton.Label"/>

                <Description resid="TaskpaneButtonRead.Tooltip"/>

              </Supertip>

              <Icon>

                <bt:Image size="16" resid="Icon.16x16"/>

                <bt:Image size="32" resid="Icon.32x32"/>

                <bt:Image size="80" resid="Icon.80x80"/>

              </Icon>

              <Action xsi:type="ShowTaskpane">

                <SourceLocation resid="TaskpaneRead.Url"/>

                <SupportsPinning>true</SupportsPinning>

              </Action>

            </Control>

          </Group>

        </OfficeTab>

      </ExtensionPoint>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

OfficeDev / office-js

Difficulty Detecting Compose Mode on macOS in Office Add-ins #5092