We have the same problem either.
For now, we added an ugly spinner instead of a progress bar but our clients aren't happy with it.

It would be best if this topic can be priorities somehow

@doronsever
In case this is critical for you, I've just tested with editing the resulted ngsw-worker.js file and it works:
I've installed gulp and gulp-replace 😬 and created a gulp task that replaces onFetch(event) { with:

onFetch(event) {
    if (event.request.url.indexOf('/upload') !== -1) { return; }

in the dist/ngsw-worker.js file and then my build script became ng build [whatever options I have] && gulp swAjaxUploadFix (or I could have used the default task and simply run gulp, but I like to name my tasks).
Of course, in my case we have the convention that all upload urls contain /upload.
And also I log a big, multiple line message in the console on build so I don't forget about removing this workaround as soon as this feature gets implemented by the Angular team.
But, meanwhile, reporting the progress on uploads works! 😁
So, I just wanted to let you know it works. Because when I posted the issue, I had only read that this would fix progress reporting, and took what I read for granted, haven't tested myself. Now I have!

@MrCroft Thank you very much!
At least it's working now :)

Can this actually be put as a feature request from my end also? I think something having a key like "exclude" with interface like interface Exclude { name: string; urls: string[]; version?: number; }. There is one more open question like this in 'so. https://stackoverflow.com/questions/47693093/angular-5-and-service-worker-how-to-exclude-a-particular-path-from-ngsw-config

The only problem I see is that the check should happen asynchronously. Based on #23025 (comment) it shouldn't be possible to decide whether to handle the request or not asycnhronously. But I am wondering if calling event.waitUntil() allows us to defer the decision of whether to call event.respondWith() or not and still be able to choose not to handle the request.

I.e. something like:

onFetch(evt) {
  evt.waitUntil(asynchronouslyDecideWhetherToHandle(evt).
    then(handleIt => handleIt && evt.respondWith(...));
}

I see the point. If thats the case it definitely seems like its a tradeoff on performance and feature. May be someone is is more aware than me on the implementation can point the way forward.

This would also be useful as a workaround for Firebase uploads (#23244), video streaming (#25007) and range requests (e.g. seeking in videos) (#25865).
A possible solution could come through #20756 (comment).

I'm having the same issue when watching server sent events through an EventStream. Bypassing the 'notifications' request with aforementioned workaround fixed it for now though.

This issue is blocking rendering PDF in Chrome from 71 version

We are also having problems with PDF documents, they are correctly served by the Service worker, but they don't get rendered. Bypassing the sw with the console allows to see the PDF document.

Did you try specifying navigationUrlsexplicitly?
https://angular.io/guide/service-worker-config#navigationurls

Did you try specifying navigationUrlsexplicitly?
https://angular.io/guide/service-worker-config#navigationurls

what do you mean ? all files with extension are excluded with a glob; or am I missing something ?

as @gkalpak says, the service worker doesnt work on safari when uploading files with @angular/fire to firebase storage

Any roadmap on this issue?

Plus one for this. We're hitting issues with the service worker adding "Cache-Control" headers to external API calls which don't allow that header. As we're not in control of the API we can't modify the accept headers on it. Therefore we need some way to have the browser do these API calls normally.

@lyashu5040, it won't be able to address those cases (but it will address cases all other cases).
It is not an ideal solution, but it is the best we've come up with so far 😁

BTW, for anyone desperate for a work-around, I've seen people successfully wrapping ngsw-worker.js in their own script that catches fetch events early and stops their propagation to ngsw-worker.js. Off the top of my head, something like:

// Catch `fetch` events and prevent specific ones from propagating to the Angular SW.
self.addEventListener('fetch', evt => {
  const req = evt.request;

  if (/* `req` matches some criteria */) {
    evt.stopImmediatePropagation();
  }
});

// Import the Angular SW to do the heavy-lifting.
self.importScripts('./ngsw-worker.js');

_{If you do that, you might want to set updateViaCache: 'all', when registering the SW.}

I am not sure this will work (and it is definitely not an officially recommended approach 😇), but might be good enough as a work-around.

Started work on a pull request: #30010 @gkalpak

I found a fairly simple workaround if you want your SW to completely "ignore" a specific path (for example we had a few paths that get redirected to another domain, which we did not want to be handled by our SW) :
By adding paths, you want to ignore, with a cacheConfig.strategy of "freshness" as a dataGroup the service worker will automatically load the content from the server (given that the timeout is not reached.)

eg ngsw-config.json:

...
"dataGroups": [
{
  "name": "cloudfront behaviours",
  "urls": [
    // for these paths the Service Worker is ignored
    "/terms",
    "/blog-posts"
  ],
  "cacheConfig": {
    "maxSize": 0,
    "maxAge": "0u",
    "strategy": "freshness"
  }
},
... 

@frankadrian, this is something different. In this case, the SW will still handle the request, but it will just choose to forward it to the server and forward the response back to the app. This is already possible without specifying a data-group (i.e. is the difault behavior).

This thread is about having the SW not handle the request (and let the browser handle it instead). There is a subtle difference, but it can be important in certain cases (for reasons explained above).

Please don't close this. As was stressed before the current implementation doesn't fix all usecases, eg. when using firebase SDK.

@aSegatto Have you tried using an HttpInterceptor: https://angular.io/api/common/http/HttpInterceptor

It could maybe capture the requests made by the firebase SDK? And in that case add the ngsw-bypass header.

Guide for using HttpInterceptor can be found here: https://angular.io/guide/http#intercepting-requests-and-responses

@petersalomonsen, I don't think the Firebase SDK goes through the HttpClient (for all requests), but I might be wrong.

@aSegatto, fair enough. I suggest we open a new issue specifically for situations where using an HTTP header or query param is not possible (since that is slightly different than the original issue). Can you do that (and reference this issue for context)? (Also, I think it is worth mentioning this work-around for visibility: #21191 (comment))

@aSegatto @gkalpak I've had a quick look at AngularFire and seems like it's not using HttpClient. But even when this is the case we can still intercept XMLHttpRequest for example like this:

const originalOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function( method, url) { 
	originalOpen.apply(this,[method, url]);
	this.setRequestHeader('ngsw-bybass','true');
};

Then any library using XMLHttpRequest in your client will set the ngsw-bypass header. You can extend this to check for specific URLs / methods.

We could of course add another feature to the serviceworker by using the message port to send lists of URLs to be bypassed (and the serviceworker could store this in a map), but I think I would try out the client side interception strategy first.

@petersalomonsen Thanks for your suggestions. I don't know if modifying XMLHttpRequest would work , because i don't know how the requests are made from the firebase sdk (maybe they also use fetch API ? ), but this could be an approach...
Message port IMHO is more clean as it doesn't couple to the sdk implementation.

@gkalpak Thanks, I open another issue

To expand upon @MrCroft 's workaround, in case anyone isn't using gulp/grunt or other build tool, you can modify the ngsw-worker.js file using sed and easily integrate the workaround into your package.json scripts. Here's the code I'm using on MacOS 10.14.5:

in package.json

"scripts": {
    …
    "editngsw": "sed -i '' \"s/onFetch(event) {/onFetch(event) { if (event.request.url.indexOf('firebasestorage.googleapis.com') !== -1) { return; }/g\" www/ngsw-worker.js",
    "build": "ng build --prod=true && npm run editngsw"
  },

or for Ionic

"scripts": {
    …
    "editngsw": "sed -i '' \"s/onFetch(event) {/onFetch(event) { if (event.request.url.indexOf('firebasestorage.googleapis.com') !== -1) { return; }/g\" www/ngsw-worker.js",
    "build": "ionic build --prod && npm run editngsw"
  },

Please note: the above code assumes you're using www as your build output directory (vs dist, etc).

@briznad @MrCroft many thanks for the solution! It also works for me :)
There is any way to write the code at the @angular/pwa library in order to avoid tho search for this bug? @gkalpak @AngularFirebase @fireship-io Thanks in advance!! Federico

@BluebambooSRL: Sorry, I disn't understand your question 😕 Can you clarify?

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}