Unified-manifest personal tab: host iframe stays at about:blank in Outlook until an add-in task pane is opened

Hi bertrand,

Thank you for reaching out and for the detailed diagnostics.

Based on the evidence, this strongly suggests an Outlook host-side initialization or iframe lifecycle issue rather than a problem with your manifest, TeamsJS version, page response, or sandbox configuration.

Outlook successfully requests the tab URL and receives a 200 response, but the iframe remains on about:blank. This indicates that the response is not becoming the iframe’s active document, so your application code never runs and app.notifySuccess() cannot execute.

Opening a classic add-in task pane appears to initialize session-level Outlook add-in infrastructure that the MetaOS personal-tab host may also depend on. After that state is initialized, the same URL and byte-identical response load correctly. The exact internal dependency is not publicly documented and will require investigation by the Outlook or MetaOS engineering team.

The empty hubBubbleErrorUI message also appears to be a secondary host-side issue because Outlook displays the error surface without providing a visible diagnostic message.

At this stage, I do not see a clear application-side fix. Opening a classic task pane first may serve as a temporary workaround, but it is not a suitable long-term solution.

I recommend contacting your IT administrator. They can submit a support request through the Microsoft 365 Admin Center as the primary next step. This will allow Microsoft Support to collect tenant-specific diagnostics, review correlation and session data, and escalate the issue to the appropriate engineering team if required.

When creating the ticket, please include the failing and working HAR files, console logs, DOM snapshots, Outlook build details, tenant and application IDs, correlation IDs, a minimal reproduction package, and the related GitHub issues. You may also add your findings to the relevant GitHub issue, or create a new issue if necessary, to help the developer team track the reproducible platform behavior. However, GitHub should be considered a supplementary channel rather than a replacement for the official support ticket.

For guidance on how to request support in the admin center, please refer to: Get support - Microsoft 365 admin.   

In case you do not know who is your IT admin, kindly refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support  

I hope your issue gets resolved soon.

Thank you for the analysis — it matches each of our measurements.

An update on the recommended next step, for the record on this thread.

We had already submitted service request [Moderator note: Personally Identifiable Information removed] through the Microsoft 365 Admin Center on 24 August 2026, with the full diagnostics attached: unfiltered HAR captures of both the failing and the working state, DOM snapshots, a console capture and a Problem Steps Recorder recording.

The case was archived on 8 September. Support then confirmed by telephone that they cannot investigate it, as third-party Office add-ins fall outside their scope, and referred us to developer support. The link we were given points to Premier/Unified Support — a paid contract we do not hold.

So the two channels currently point at each other: admin-center support treats this as a third-party add-in issue and refers us to developer support; the developer channel identifies it as an Outlook host issue and refers us back to admin-center support. There is no route between them that we can take on our own.

Everything needed to trace this server-side is already attached to service request [Moderator note: Personally Identifiable Information removed], and we can provide it again on request:

• Outlook on the web build (x-owa-version): 15.21.360.10
• Both states were captured in one and the same OWA session, 86 seconds apart:
  • failing state (tab blank): 2026-08-28 19:34:57.726 → 19:35:45.599 UTC
    • working state (after a task pane was opened): 2026-08-28 19:36:23.371 → 19:36:47.997 UTC
    • Tenant ID, x-owa-sessionid and all x-owa-correlationid / client-request-id values are in the attached HAR files. Not posted here, as this thread is public.

One session, one mailbox server, 86 seconds apart — the before/after comparison is directly traceable in server-side telemetry.

If a Microsoft engineer comes across this thread: this is a reproducible platform behaviour. The host creates app-host-iframe with the correct src; the page returns 200 with headers identical to the working state — same etag, same content-length, no X-Frame-Options, no CSP — and the frame's document stays about:blank until an add-in runtime has been loaded in the session. Our code never runs, so app.notifySuccess() is never called. We would like this routed to the Outlook / MetaOS team. We will also file it on OfficeDev/office-js.