DOMFormData is not currently available in workers due FormData (which DOMFormDatas are passed to for conversion to an HTTP body) currently depending on the Document/Page to do file replacement.
As noted, the crux of the issue is that FormData class uses the Page to allow a hosting app to generate a file replacement for things like bundles. This was added in https://trac.webkit.org/changeset/32666/webkit (~9 years ago).
My guess is that we can remove the delegation, and use the now available platform standard ways to detect bundles and generate the replacement.
Indeed, it looks like we have most of the infrastructure in place to do this for Blobs already (File::shouldReplaceFile, File::computeNameAndContentTypeForReplacedFile, BlobDataFileReference::generateReplacementFile).
There is some performance improvement to make potentially - I think that there are situations where we compress the same bundle twice, using the delegate first, and then in the Networking process using WebKit functionality again.
(In reply to Sam Weinig from comment #2)
> Indeed, it looks like we have most of the infrastructure in place to do this
> for Blobs already (File::shouldReplaceFile,
This has been removed now so we should be able to expose DOMFormData to workers
Created attachment 383274 [details]
We probably need to handle the call of MIMETypeRegistry::getMIMETypeForExtension
Created attachment 383275 [details]
Created attachment 383282 [details]
Created attachment 383289 [details]
The commit-queue encountered the following flaky tests while processing attachment 383289 [details]:
inspector/model/remote-object-weak-collection.html bug 202932 (authors: email@example.com and firstname.lastname@example.org)
The commit-queue is continuing to process your patch.
Comment on attachment 383289 [details]
Clearing flags on attachment: 383289
Committed r252349: <https://trac.webkit.org/changeset/252349>
All reviewed patches have been landed. Closing bug.