I'm sorry. I mistook the link element. The correct element is as follows. 
<link rel="manifest" href="/manifest.json">

reporter@ - Thanks for filing the issue...!!

Could you please provide a sample test extension file/url to test the issue from TE-end. This will help us in triaging the issue further.

Thanks...!!

I will attach a sample file.
1. After deployment, place it on the web server.
2. Access cookie.html and click the "Add Cookie" link.
3. Display the Network tab of Developer Tools and reload the page.
4. Click manifest.json and check the request header.

Deleted: sample.tar.gz 846 bytes

sample.tar.gz 846 bytes Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The manifest is definitely requested with the no cookies flags:  DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES

I defer to the relevant blink folks over whether this is expected.

https://cs.chromium.org/chromium/src/content/renderer/fetchers/manifest_fetcher.cc
Our code intentionally does it, but it's unclear if this is correct in terms of the spec.

Existing code does:
 1. if crossOrigin attribute's value is 'use-credentials', then set request's credentials to 'include'.
 2. otherwise, set it to 'omit' (and set fetch request mode to 'cors' too)

1. is what spec requires in the 7.1 step 7; https://w3c.github.io/manifest/#obtaining

But, it's still unclear to me on 2. Probably, making 'no-cors' request is desirable if crossOrigin is not set?

cc: yhirano@

Thank you for your answer.

If crossOrigin is not set, I'm worried about "no-cors" or "omit".
I think that there is no problem with "omit".

The cors behavior should be clarified by the spec & feature owners.