Office.context.mailbox.item.body.getAsync returns incorrect HTML for nested lists on Mac Outlook Desktop app #5253

dbrar-tf · 2025-01-08T19:40:41Z

Environment

Platform: Mac Desktop
Host: Outlook
Office version number: Microsoft Outlook for Mac Version 16.92 (License: Microsoft 365 Subscription)
Operating System: macOS 15.2 (24C101)
Browser (if using Office on the web): Not applicable

Expected behavior

When using Office.context.mailbox.item.body.getAsync to retrieve the HTML of the email body, the output should preserve the correct formatting of lists, including nested lists (up to third level and beyond). This is what i get from web version of outlook

For example:

<ol start="1" data-editing-info="{&quot;applyListStyleFromLevel&quot;:true}" style="list-style-type: decimal;">
   <li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
      <div class="elementToProof">val1</div>
   </li>
   <li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
      <div class="elementToProof">val2</div>
   </li>
   <ol start="1" data-editing-info="{&quot;applyListStyleFromLevel&quot;:true}" style="list-style-type: lower-alpha;">
      <li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
         <div class="elementToProof">val3</div>
      </li>
      <li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
         <div class="elementToProof">val4</div>
      </li>
      <ol start="1" data-editing-info="{&quot;applyListStyleFromLevel&quot;:true}" style="list-style-type: lower-roman;">
         <li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
            <div class="elementToProof">val5</div>
         </li>
      </ol>
   </ol>
   <li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
      <div class="elementToProof">val6</div>
   </li>
</ol>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">thanks</div>

The output should not break the list structure when a third-level list item is present.

Current behavior

When using Office.context.mailbox.item.body.getAsync on the Mac Desktop Outlook app, the HTML output breaks nested lists at the third level. Instead of preserving the correct list structure, the third-level item is wrapped in a

tag, causing a new list to be started incorrectly.

Example output:

<body lang=EN-CA link="#467886" vlink="#96607D" style='tab-interval:36.0pt;word-wrap:break-word'>
      <div class=WordSection1>
         <div>
            <ol style='margin-top:0cm' start=1 type=1>
               <li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>
                  <span style='mso-fareast-font-family:"Times New Roman"'>
                     Val1
                     <o:p></o:p>
                  </span>
               </li>
               <li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>
                  <span style='mso-fareast-font-family:"Times New Roman"'>
                     Val2
                     <o:p></o:p>
                  </span>
               </li>
            </ol>
            <ol style='margin-top:0cm' start=2 type=1>
               <ol style='margin-top:0cm' start=1 type=a>
                  <li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level2 lfo1'>
                     <span style='mso-fareast-font-family:"Times New Roman"'>
                        Val3
                        <o:p></o:p>
                     </span>
                  </li>
                  <li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level2 lfo1'>
                     <span style='mso-fareast-font-family:"Times New Roman"'>
                        Val4
                        <o:p></o:p>
                     </span>
                  </li>
               </ol>
            </ol>
            <p class=MsoListParagraph style='margin-left:108.0pt;text-indent:-108.0pt;mso-text-indent-alt:-9.0pt;mso-list:l0 level3 lfo1'>
               <![if !supportLists]><span style='mso-fareast-font-family:Aptos'><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>i.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]>
               <span style='mso-fareast-font-family:"Times New Roman"'>
                  Val5
                  <o:p></o:p>
               </span>
            </p>
            <ol style='margin-top:0cm' start=3 type=1>
               <li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>
                  <span style='mso-fareast-font-family:"Times New Roman"'>
                     Val6
                     <o:p></o:p>
                  </span>
               </li>
            </ol>
            <p class=MsoNormal>
               <span style='mso-fareast-font-family:"Times New Roman"'>
                  <o:p>&nbsp;</o:p>
               </span>
            </p>
            <p class=MsoNormal>
               <span style='mso-fareast-font-family:"Times New Roman"'>
                  thanks
                  <o:p></o:p>
               </span>
            </p>
         </div>
      </div>
   </body>

This behavior only occurs on the Mac Desktop app. The Outlook Web version handles nested lists correctly.

Steps to reproduce

Open the Mac Desktop Outlook app.
Create an email with a nested list up to the third level.
Use the following code to retrieve the email body:

Office.context.mailbox.item.body.getAsync("html", function (result) {
    console.log(result.value);
});

Inspect the retrieved HTML and observe that the third-level list item is incorrectly wrapped in a

tag.

Link to live example(s)

Not applicable (no live link, but repro steps provided above).

Provide additional details

This issue occurs only on the Mac Desktop Outlook app. The issue does not occur when using Outlook on the Web.

Context

I am working on an add-in that processes the HTML body of emails. The incorrect formatting of nested lists disrupts the handling of email content. It leads to unintended list breaks and affects how lists are displayed in our application.

This issue is critical for maintaining consistency between desktop and web versions of our add-in.

Useful logs

Console errors: No console errors, but the HTML output is incorrect.
Screenshots: input

Test file: Not applicable.

The text was updated successfully, but these errors were encountered:

sivachandran-msft · 2025-01-16T11:10:18Z

Hi @dbrar-tf , Thanks for reporting and sharing the required details.

What is the usecase you are trying to meet here? The formatting of html may looks different in OWA & Mac but when you use the same string in Office.context.mailbox.item.body.setAsync, the email body will have same list as you formatted earlier.

dbrar-tf · 2025-01-20T15:16:37Z

Our Use Case:

We are developing an Outlook add-in that retrieves the email body via Office.context.mailbox.item.body.getAsync. Our workflow is as follows:

Retrieve the Email Body:
We use getAsync to extract the HTML content from the email.
Process and Forward:
Once we retrieve the email body, we send it to our web application, which processes and forwards the email as needed.

The Issue:

We’ve observed that the HTML formatting (for example, how lists, spacing, or other HTML elements are rendered) differs between the Outlook desktop app and the Outlook Web App (OWA). This discrepancy might affect how emails are displayed after they’ve been processed or forwarded by our system.

Key Points to Address:

Different Retrieval Behavior:
While the support team’s answer about setAsync assures consistency when inserting HTML into an email (thus forcing the formatted look), our issue is with retrieving the HTML. Different Outlook clients seem to have their own way of processing or rendering the stored HTML when it is retrieved.
Client-Specific Rendering:
The variations we see suggest that the email clients (Outlook desktop vs. OWA) might be modifying or interpreting the HTML differently either when storing the content or when rendering it for display.
Impact on Our Workflow:
Since our add-in relies on the HTML retrieved by getAsync for further processing in our web application, these differences could lead to inconsistent presentation or processing of the email content.

What We Need Clarification On:

Is there a recommended approach for ensuring the HTML remains consistent when retrieved via getAsync across different Outlook clients?
Are there known client-specific behaviors that we could work around (e.g., by post-processing the retrieved HTML to standardize the formatting)?
Could there be a setting or best practice when composing or retrieving emails that minimizes these discrepancies?

neprasad-microsoft · 2025-01-30T16:34:14Z

Hi @dbrar-tf
Can you try with the New Editor on Outlook Mac. This issue should be fixed there.

dbrar-tf · 2025-01-31T14:57:03Z

LGTM, it's fixed, thanks.

microsoft-github-policy-service bot added the Needs: triage 🔍 New issue, needs PM on rotation to triage ASAP label Jan 8, 2025

exextoc added Needs: attention 👋 Waiting on Microsoft to provide feedback Area: Outlook Issue related to Outlook add-ins and removed Needs: triage 🔍 New issue, needs PM on rotation to triage ASAP labels Jan 8, 2025

exextoc self-assigned this Jan 8, 2025

sivachandran-msft added Needs: author feedback Waiting for author (creator) of Issue to provide more info and removed Needs: attention 👋 Waiting on Microsoft to provide feedback labels Jan 16, 2025

microsoft-github-policy-service bot added the Status: no recent activity Issue or PR is stale (no recent activity) label Jan 20, 2025

microsoft-github-policy-service bot added Needs: attention 👋 Waiting on Microsoft to provide feedback and removed Status: no recent activity Issue or PR is stale (no recent activity) Needs: author feedback Waiting for author (creator) of Issue to provide more info labels Jan 20, 2025

neprasad-microsoft added Needs: author feedback Waiting for author (creator) of Issue to provide more info and removed Needs: attention 👋 Waiting on Microsoft to provide feedback labels Jan 30, 2025

dbrar-tf closed this as completed Jan 31, 2025

microsoft-github-policy-service bot added Needs: attention 👋 Waiting on Microsoft to provide feedback and removed Needs: author feedback Waiting for author (creator) of Issue to provide more info labels Jan 31, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Office.context.mailbox.item.body.getAsync returns incorrect HTML for nested lists on Mac Outlook Desktop app #5253

Office.context.mailbox.item.body.getAsync returns incorrect HTML for nested lists on Mac Outlook Desktop app #5253

dbrar-tf commented Jan 8, 2025

sivachandran-msft commented Jan 16, 2025

dbrar-tf commented Jan 20, 2025

neprasad-microsoft commented Jan 30, 2025

dbrar-tf commented Jan 31, 2025

Office.context.mailbox.item.body.getAsync returns incorrect HTML for nested lists on Mac Outlook Desktop app #5253

Office.context.mailbox.item.body.getAsync returns incorrect HTML for nested lists on Mac Outlook Desktop app #5253

Comments

dbrar-tf commented Jan 8, 2025

Environment

Expected behavior

Current behavior

Steps to reproduce

Link to live example(s)

Provide additional details

Context

sivachandran-msft commented Jan 16, 2025

dbrar-tf commented Jan 20, 2025

neprasad-microsoft commented Jan 30, 2025

dbrar-tf commented Jan 31, 2025