This issue seems to be out of TE-scope. Hence, adding label TE-NeedsTriageHelp for further investigation.

Thanks...!!

Looks like this error is only generated by AncestorThrottle, and is caused by x-frame-options preventing a request?

Hi Kavita bora. Thank you for letting us know about this problem. Would you have a link on which you can click to reproduce the bug?

Removing TE-NeedsTriageHelp.

Perhaps we're running downloads through the same throttle as navigations? That would be pretty strange if the download is initiated via XHR, but possible, I suppose?

Sorry we can not provide you the link to reproduce the bug.Yes we are downloading excel file using ajax.
Ajax downloading was working fine in earlier version.Problem has started with latest browser update.

Can you give any more detail beyond "using ajax"? :) Do you mean jQuery's `ajax()` (http://api.jquery.com/jquery.ajax/)? `XMLHttpRequest`? `fetch()`? It would be really helpful to understand how you're making the request so we can try to reproduce it locally.

Sure, we are using jquery file dowload code is below
$(".exportProductDetail").click(function () {
    jQuery.fileDownload("././download/exportProductDetail", {
        httpMethod: "POST",
        data: {
            param: JSON.stringify({
                productId: selectedData.product_id,
                openCycleTime: selectedData.openCycleTime,
                closeCycleTime: selectedData.closeCycleTime,
                transactionType: jQuery("#transactionType").val()
            })
        }
    });
});

Assuming that https://github.com/johnculviner/jquery.fileDownload is the plugin you're using, it looks like it's using an `<iframe>` internally to do the download. Maybe we're processing the `X-Frame-Options` header before we're parsing the `Content-Disposition` header that would cause a download?

Thanks for #8.

It looks like it uses jQuery.fileDownload.
```
jQuery File Download is a cross server platform compatible jQuery plugin that allows for an Ajax-like file download experience that isn't normally possible using the web.
```

https://github.com/johnculviner/jquery.fileDownload/blob/master/src/Scripts/jquery.fileDownload.js
An iframe is created somewhere in the code source.
"//create a temporary iframe that is used to request the fileUrl as a GET request"

That could explains a lot of things.

As you said "we're processing the `X-Frame-Options` header before we're parsing the `Content-Disposition` header" but I am not parsing any header in my code.

If the X-frame-options of the downloaded resource indicate it can't be loaded in a frame (Or if it's a cross-site resource and the header insists that the resource be loaded only in same-origin contexts), Chrome won't download the resource.

If you provide a net-internals log of the error, I'll take a look, but this may be working as-intended.  Instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

It may also be that this is not working as intended - the logic for this recently moved locations, and it could be that it went from being after we determine a resource is a download (And pass ownership to the download subsystem) to before we determine it's a download, which may or may not be intended.

kavita.bora@: Would you be able to provide a net-internals log, as mmenke@ asked? That would help us figure out what's being requested and how.

https://codereview.chromium.org/2874933002/ solved the problem.

Thanks kavita.bora@!