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

bertrand soual 0 Reputation points
2026-09-08T15:07:18.84+00:00

Centrally deployed unified-manifest app with a staticTabs personal tab (scopes: ["personal"], context: ["personalTab"]). Manifest schema 1.20, @microsoft/teams-js 2.55.0 — both above the documented minimums (1.13 / 2.19.0).

In Outlook on the web and in new Outlook for Windows, the app icon appears in the left rail and the tab header shows the app name, but the content area stays blank under the host's hubBubbleErrorUI message bar — whose title span is empty (::after { content: " " }, measured 0 × 0), so no error text is shown.

What we measured (unfiltered HAR + DOM inspection, normal window, signed in):

  • The host creates <iframe data-tid="app-host-iframe"> with the correct src and sandbox including allow-scripts allow-same-origin.
  • Our page is fetched: 200, sec-fetch-dest: iframe, no X-Frame-Options, no Content-Security-Policy.
  • The frame's live document is about:blank, with empty <head> and <body>. Our code therefore never runs and app.notifySuccess() is never called.
  • 22 console errors, all from owa.* host scripts, none from our origin. Two info messages from office.js: Office.js is loaded outside of Office client and The add-in is not hosted in plain browser top window.

Opening any classic add-in task pane first makes the same tab render normally for the rest of the session. In that state, the same iframe — same src, same sandbox, same title — holds our real document, and the HTTP response for the page is byte-identical (same etag, same content-length, same headers). The only structural difference between the two states is the frame's document.

Ruled out: browser cache and private browsing; Chrome, Edge and the desktop client; two separate app registrations; three accounts in the tenant including one with no admin role; and declaring the task pane and the personal tab in a single unified manifest.

Question: what does loading an add-in runtime put into the Outlook shell that the MetaOS tab host depends on — and what would cause that host to leave the frame at about:blank while the page it requested returned 200?

Possibly related: OfficeDev/office-js #6768, OfficeDev/microsoft-365-agents-toolkit #9659.

Microsoft 365 and Office | Development | Office JavaScript API
0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

  3. bertrand soual 0 Reputation points
    2026-09-08T17:15:06.6+00:00

    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.

    Was this answer helpful?

  4. Jay1 Tran 515 Reputation points Independent Advisor
    2026-09-08T16:03:23.7433333+00:00

    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.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.