IE11 ignores X-Frame-Options after redirect

I have a web application that is opened via a Facebook Messenger app. On mobile it's opened in Facebook Messenger's webview, on desktop it opens in an iFrame. This works in all browsers except IE11.

We are setting an X-Frame-Options header of 'ALLOW-FROM https://www.messenger.com'. When the application is first loaded in the iFrame it loads with no issues. Then the application responds to a request with a 302 and redirects. It's the page that gets redirected to that shows the error "This content cannot be displayed in a Frame". There is no error in the console like there usually is when iFrame content is blocked in other browsers.

Is there some aspect of redirecting in an iFrame that IE11 does not support?

More detail of application: This is a Django server-side rendered web app using JS on the client. I'll try to break down the order of operations:

Request 1: GET to endpoint1 which returns document - this is displayed in the iFrame successfully

Request 2: POST to endpoint1 from JS on the client

const formData = new FormData();

        formData.append('psid', thread_context.psid);
        formData.append('tid', thread_context.tid);

        const xhr = new XMLHttpRequest();

        xhr.onload = function (event) {
            if (this.status !== 200) {
                handleError(this);
                return;
            }

            window.location.href = this.responseURL;
        };
        xhr.onerror = handleError;

        xhr.open('POST', postUrl);
        xhr.send(formData);

Response is status code 302 with a location header

Request 3: GET to the location returned in the 302 response. The response is status code 200 and includes the document in the body. This causes the xhr.onload above to fire and then calls the window.location.href to redirect to the new location returned previously.

Request 4: GET as a result of updating the window.location.href. Response is status code 200. This is when the browser displays the "content cannot be displayed in a Frame" message.

Each one of these requests includes the X-Frame-Options header of 'ALLOW-FROM https://www.messenger.com' in the response.

So it turns out the "content cannot be displayed in Frame" message was a red herring. The problem is really due to setting:

window.location.href = this.responseURL;

In IE and perhaps older versions of Edge responseURL is not a supported property of XMLHttpRequest. Additionally it doesn't seem possible to get the request URL after a 302 in IE. As a result my solution will be to rewrite our usage of returning the 302 to begin with and instead return a JSON response with the URL to redirect to.