Launching an LTI® Tool Outside the Iframe
The short answer
A new tab is a first-party context, so cookies and browser storage work normally there. That makes it the dependable fallback when third-party storage restrictions break your tool inside the LMS iframe. The cost is that the integration stops feeling seamless, and that deep linking needs deliberate handling or it will silently stop working.
When this is the right answer
Leaving the iframe is a real loss — the learner leaves the LMS, and the integration feels like a link rather than a feature. It is worth it when:
- Your application's session handling is not something you can change, because it is a framework's, a vendor's, or older than anyone still on the team.
- You support customers on browsers with the strictest defaults and cannot fix every path in time.
- The tool needs a substantial working session — an exam, a long editing task — where an iframe was always going to be cramped.
If you can change how the session is carried, do that first. Passing a token in the URL, described in the cookie article, keeps the seamless launch and solves the same problem.
Two ways to get there
Ask the platform to do it
Most platforms let an administrator configure a placement to open in a new window. When the platform does it, the tool never renders in an iframe at all, which is the cleanest version.
The catch is that this is set per placement by a human. One link configured the old way and you are back in an iframe with no session. Treat it as the preferred path, not the only one.
The platform also tells you what it intended: the launch carries a presentation
document target — iframe, window or embed — describing how the tool was
meant to be displayed. It reports the platform's intent, not the browser's
reality, so it is useful context rather than something to branch on.
Detect the iframe and offer a way out
More reliable, because it does not depend on configuration. It relies on
window.top being
unreadable across origins:
function inIframe () {
try {
return window.self !== window.top;
} catch (e) {
return true;
}
}
The try/catch matters. Reading window.top across origins throws, and that
throw is itself the answer — if you cannot see the top window, you are in someone
else's frame.
Then give the user a button rather than opening automatically. A popup triggered without user interaction gets blocked, and the user sees nothing at all:
{inIframe() && (
<button onClick={() => window.open(window.location.href)}>
Open in a new tab
</button>
)}
Keeping the launch context
This is where implementations go wrong. Opening a new tab starts a fresh browsing context, so anything the launch left in the iframe's storage is gone.
What survives is whatever is in the URL. If your launch context is a token in the
query string, window.location.href carries it into the new tab and the tool
picks up exactly where it was.
With LTIAAS this works because the ltik is a query parameter,
not a stored value. It is a signed pointer to launch data held server-side, valid
for 24 hours, and redeeming it requires your API key as well — so it works from
any tab without becoming something an attacker can use on its own.
If your launch context lives in a cookie or in sessionStorage, moving it into
the URL is the change that makes new-tab launching viable at all.
Deep linking needs different handling
Opening a plain launch in a new tab is fine. Doing the same during deep linking breaks it, and it breaks quietly.
Deep linking ends with the tool submitting a signed Deep Linking 2.0 response back to the LMS through the frame it was launched in. Leave that frame and there is nothing to submit to — the user picks their content, the tool believes it succeeded, and the LMS never receives the selection.
Opening a deep linking launch in a new tab will break content selection on most platforms unless you carry the result back explicitly.
Three ways to handle it, best first:
Do not require a login for deep linking. Often the only reason to leave the iframe is a session, and content selection frequently does not need one. Read the launch data, show the picker, submit the response — all inside the iframe, no session, no cookie, nothing to break. This is the answer for most tools.
Poll from the iframe. If the picker genuinely needs a logged-in session, open it in a new tab but leave the iframe in place, polling your back end once a second to see whether a selection has been recorded. When one appears, the iframe submits the deep linking response from where it always was. Key the stored selection on the launch token so one user's iframe cannot collect another's choice.
Use a WebSocket. The same shape with a live connection instead of polling. Only worth it if you already run WebSockets — otherwise it is more reliability surface for a one-second saving.
The LTIAAS specifics for each, including the endpoints involved, are in the cookies guide.
What to check before shipping
- The new tab opens from a user action, not automatically, or it gets blocked.
- The launch context is in the URL and nothing is read from iframe storage.
- Deep linking is tested separately from a plain launch.
- The button appears only inside an iframe — offering it in a first-party tab is confusing and looks broken.
Common questions
Why would I open an LTI® tool in a new tab?
Because a new tab is a first-party context, so ordinary cookies and browser storage work normally. It is the reliable fallback when your tool depends on a session that browsers will not let you keep inside an iframe.
Does the launch context survive a new tab?
It depends on how the context is carried. Anything held in browser storage tied to the iframe does not survive. A token passed as a URL parameter does, which is why LTIAAS puts the ltik in the URL.
Why does deep linking break in a new tab?
Deep linking finishes by posting the selection back to the LMS through the frame that launched the tool. Leave that frame and there is nothing to post to, so the selection is never delivered.
Can I ask the LMS to always open in a new tab?
Most platforms have a setting for it, and it is worth asking for. Do not rely on it alone — it is set per placement by an administrator, so one misconfigured link brings the iframe back.
Next
- Why LTI® launches break without third-party cookies
- LTI® Platform Storage explained — the fix that keeps you in the iframe
- Why your LTI® tool shows a blank page
