Closed Bug 1424701 Opened 2 years ago Closed 2 years ago
Posting a file fails with pass-through Fetch
Event handler in e10s mode
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce: https://post-file-serviceworker-test.glitch.me/ 1. Click the file input and select a file. 1. JS will post the file to the server. 1. See the console. Without the service worker (shift+reload) the server posts the file back. However, this fails when the service worker is controlling the page. The service worker sees the body & can read it, but it appears to get lost when the actual fetch happens. I added a "Send hello world blob" button which sends a JS-constructed blob. This appears to work fine, so the problem isn't universal to all blobs.
This works in non-e10s mode, but fails in e10s mode.
Summary: Posting a file fails if there's a service worker → Posting a file fails if there's a service worker in e10s mode
Clarify this is a pass-through FetchEvent handler.
Summary: Posting a file fails if there's a service worker in e10s mode → Posting a file fails with pass-through FetchEvent handler in e10s mode
Component: Untriaged → DOM: File
Product: Firefox → Core
Note, according to the network monitor we are setting the content length correctly on the service worker fetch(event.request) channel. I guess that's explicitly set by FetchDriver after it extracts it from the blob in the child, though.
Assignee: nobody → amarchesini
Apologies for all the cloning in the original test, I was trying to see at what point the browser loses track of the body.
(In reply to Jake Archibald from comment #5) > Apologies for all the cloning in the original test, I was trying to see at > what point the browser loses track of the body. No problem. Turns out it didn't matter much since we do a clone internally when performing a service worker interception. Thanks for the reduced test case!
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
bkelly, can you reproduce it with the latest nightly? I think I fixed the problem in bug 1421094 making nsIUploadChannel2::cloneUploadStream to pass the length of the stream (content-length). I mark it as duplicate but in case I'm wrong, reopen it. Maybe we should uplift bug 1421094.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1421094
Yes, its fixed for me now. Thanks! I think uplifting would be nice, but not worth it if the patches are risky. Currently chrome fails this test case as well. Can you please write a WPT test for this, though? I'm going to reopen this bug to do that.
Status: RESOLVED → REOPENED
Depends on: 1421094
Flags: needinfo?(bkelly) → needinfo?(amarchesini)
Resolution: DUPLICATE → ---
Currently it's not possible to simulate a file selection for a <input type=file> in a WPT. See https://github.com/w3c/web-platform-tests/issues/8114
It would be nice to have a browser chrome test I guess, then.
Maybe there's a way to create this failure case without a file input? Maybe getting the blob from IndexedDB or the cache API would do it?
Attachment #8941413 - Flags: review?(bkelly) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/479b32d510f5 Test for uploading files via ServiceWorker, r=bkelly
You need to log in before you can comment on or make changes to this bug.