New issue
Advanced search Search tips

Issue 899334 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2019-03-01
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Service Worker not capturing fetch event inside Data: URI

Reported by crb...@gmail.com, Oct 26

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce the problem:
1. register service worker with 'fetch' interception
2. open any data: URI than includes iframe with SW-interceptable URL

What is the expected behavior?
response should be produced from service worker

What went wrong?
service worker was bypassed, response was served from server

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 10.0
Flash Version: 

Also repoducible on Chrome Canary 72.0.3592.0; works as expected on Edge 18, FF 64
 
index.html
104 bytes View Download
sw.js
405 bytes View Download
Caddyfile
128 bytes View Download
sw.zip
757 bytes Download
Components: Blink>ServiceWorker
Labels: Needs-Triage-M69
Does a blob URL iframe work?
Yes. Blob URL iframe -> service worker iFrame & srcset iframe -> service worker iFrame works as expected; it is only data: URL case
Cc: phanindra.mandapaka@chromium.org
Labels: Triaged-ET Needs-Feedback
Thanks for the issue...

Tried to reproduce the issue on latest chrome stable 70.0.3538.77 using Windows 10. Attaching screen-cast for reference.
Steps: 
------
1. Launched reported chrome 
2. Downloaded given given all attached file and kept in one folder 
3. Opened the html file and >> Opened Dev tools >> Applications >> service Workers 
4. With checked and unchecked the bypass >> observed the behavior as per attached screencast
As we have observed the responses from server 

@Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end also upgrade to latest chrome : https://www.chromium.org/getting-involved/dev-channel ". Let us know whether issue still persists.

Thanks.!
899334.mp4
4.7 MB View Download
My bad - added a bit of code in SW-generated page that was acting weird. I've changed a SW code a bit, to make it work. Updated sw.js to make a good demo.

Checked on 
- 70.0.3538.77 (Official Build) (64-bit)
- 72.0.3595.2, dev (64 bit) 
- 72.0.3598.0 (Official Build) canary (32-bit)

I've recorded a video of what's happening on Chrome dev.

and got same behavior everywhere
sw.js
635 bytes View Download
Annotation (1).png
164 KB View Download
index.html
104 bytes View Download
about_blank - Google Chrome 2018-11-01 17-43-53.mp4
464 KB View Download
Project Member

Comment 7 by sheriffbot@chromium.org, Nov 1

Labels: -Needs-Feedback
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
There was a change at some point to make data URL frame get an opaque origin instead of inheriting from the parent.  I wonder if chrome is further restricting nested third parties as well for some reason.
Thanks for the explanation.
From my point of view it's more bug rather than feature, as long as

- behavior is inconsistent with other clientside-generated frames (blob & srcdoc)
- behavior is inconsistent with all other browsers (FF, Edge, did not check Safari)
- theoretically it can become a security/stability issue (if someone will decide that building a cross-domain API over service worker iframes is a good idea)
NextAction: 2019-03-01
Status: Available (was: Unconfirmed)
Action items:
- Determine whether this is the expected behavior.
- Add WPT tests for this if there are none.

Sign in to add a comment