New issue
Advanced search Search tips

Issue 661827 link

Starred by 5 users
Status: Assigned
Owner:
lazyboy@chromium.org
Cc:
jmukthavaram@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Fetch() API complains about CORS request in chrome extension background page

Reported by keven...@gmail.com, Nov 2 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce the problem:
install this extension. open background page. look at console.

What is the expected behavior?
Fetch() API from background page should treat outbound requests as same-origin requests, if target domain is whitelisted in manifest.json.

XMLHttp requests honors this rule. Fetch API does not.

What went wrong?
Fetch() API from background page should treat outbound requests as same-origin requests, if target domain is whitelisted in manifest.json.

XMLHttp requests honors this rule. Fetch API does not.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 53.0.2785.143  Channel: n/a
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 23.0 r0
fetch_extension_cors_bugs.zip
31.6 KB Download
Screen Shot 2016-11-02 at 4.53.10 PM.png
157 KB View Download

Comment 1 by jmukthavaram@chromium.org, Nov 3 2016

Cc: jmukthavaram@chromium.org
Labels: Needs-Feedback
Tested this issue on Windows 7.Mac 10.11.4 & linux Ubuntu 14.04 with chrome version-54.0.2840.87 & latest canary version-56.0.2908.0 with the above mentioned steps.

Please find the attached screenshot for reference  & Could you please let us know if i miss any steps to reproduce the issue.

Could you please provide the expected screenshot for the same to triage the issue further.

Thanks in advance.
Screen Shot 2016-11-03 at 5.28.16 PM.png
248 KB View Download

Comment 2 by keven...@gmail.com, Nov 3 2016 

@jmukthavaram@chromium.org 

Your screenshot demonstrated that this bug reproduces.

if you compare the response headers accessible by XMLHttp request (1st log, which shows "SUCCESS") VS. by Fetch() API (2nd log, which shows "ERROR" - you can see that Fetch() API can only access a small subset of all headers (content-type, expires, cache-control), as compared to the wider set of headers accessible by XMLHttp request (x-google-backends, date, content-encoding).

Comment 3 by keven...@gmail.com, Nov 3 2016 

In short, the XMLHttp request log line, shows the expected behavior - almost all response headers should be accessible by JS.

Comment 4 by shrike@chromium.org, Nov 4 2016

Components: Blink>JavaScript>API
Labels: -Needs-Feedback

Comment 5 by jochen@chromium.org, Nov 4 2016

Components: -Blink>JavaScript>API Platform>Extensions>API Blink>Network>FetchAPI

Comment 6 by tkonch...@chromium.org, Nov 4 2016

Labels: M-56 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to repro the issue on mac 10.11.6 chrome version 54.0.2840.87 and canary - 1st log shows success and 2nd log shows error

Please find the screenshot

this is a non regression issue existing since M50 50.0.2652.0 to latest canary

M30 and M40 behavior : Uncaught reference exception is displayed in console

Comment 7 by tkonch...@chromium.org, Nov 4 2016

Screen Shot 2016-11-04 at 5.08.48 PM.png
566 KB View Download

Comment 8 by asargent@chromium.org, Nov 4 2016

Owner: lazyboy@chromium.org
Status: Assigned (was: Untriaged)
Assigning to lazyboy@ since he's been doing work on service worker support and might be the most familiar with this area of code.

Comment 9 by sids.aqu...@gmail.com, Nov 1 2017 

Any updates on this issue? Asking since the last comment was a year ago.
►

Sign in to add a comment