Thanks for filing the issue!

@Reporter: Could you please share a sample extension to test, as it is out of scope for ET team to create an extension. Any further inputs from your end may help us.

Attachment fetch.xpi is a WebExtension that works on both Chrome and Firefox.
On Chrome when you load the WebExtension and then open a page (say https://google.com/) and click anywhere in the body, an errormessage will be displayed in the console stating:
	content.js:7 Fetch API cannot load https://www.google.com/robots.txt.
	Request mode is "same-origin" but the URL's origin is not same as the request origin chrome-extension://lfgfogfmnjfhenmoeblhncbcamallfmj.

Deleted: fetch.xpi 896 bytes

fetch.xpi 896 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 extension file provided at comment #3 is not compatible to chrome i.e it cannot be added to chrome extensions. It seems to compatible with firefox. Hence, could you please provide a sample extension file having manifest.json file which is compatible to chrome.

Thanks...!!

krajshree@, it's a zip archive, simply unpack it and install from that directory, open https://www.google.com, click in an empty space on the page, observe the console.

Reporter, the observed behavior is correct and matches the documentation:
https://developer.chrome.com/extensions/xhr

  > Each running extension exists within its own separate security origin.

Content scripts use the extension's origin which is why "same-origin" doesn't apply to the web page.
As for Firefox, its implementation of WebExtensions API still has many bugs/quirks even in its core parts.

@woxxom, i assumed the text at https://developer.chrome.com/extensions/xhr applied to background and popup scripts and not content scripts (although it doesn't mention that at all).

Also, if you do not explicitly set mode="same-origin" but omit the mode, the fetch does not fail.

Also, if you set mode="no-cors" (which is the default according to https://fetch.spec.whatwg.org/ ), the fetch appears to succeed but there is no responseText.

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

Able to reproduce this issue on reported version 64.0.3282.186, on latest stable 65.0.3325.181, on latest beta 66.0.3359.81 and on latest canary 67.0.3394.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.

Thanks!

[Extensions Triage] Can someone who works on fetch-api/xhr see what's the expected behavior here?

+toyoshim, I know you've been looking at extensions and CORS recently, can you take a look?

Seeing something similar with jifpbeccnghkjeaalbbjmodiffmgedin as well -- permission exists (confirmed by chrome.permissions) but CORS preflight is being issued.