Bug 182848 – Resources loaded from service workers are not downloadable

• Status: RESOLVED
• Resolution: FIXED
• Component: Service Workers

[youenn fablet]

Resources loaded from service workers are not downloadable

[youenn fablet]

Created attachment 333981 [details]
Patch

[youenn fablet]

<rdar://problem/37497961>

[Radar WebKit Bug Importer]

<rdar://problem/37592202>

[EWS Watchlist]

Comment on attachment 333981 [details]
Patch

Attachment 333981 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/6527931

New failing tests:
http/tests/security/http-0.9/xhr-blocked.html

[EWS Watchlist]

Created attachment 333990 [details]
Archive of layout-test-results from ews101 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-sierra  Platform: Mac OS X 10.12.6

[Chris Dumez]

(In reply to Build Bot from comment #5)
> Created attachment 333990 [details]
> Archive of layout-test-results from ews101 for mac-sierra
> 
> The attached test failures were seen while running run-webkit-tests on the
> mac-ews.
> Bot: ews101  Port: mac-sierra  Platform: Mac OS X 10.12.6

Thread 0:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x00007fffc5dc1e5a CFEqual + 74
1   com.apple.WebCore             	0x0000000112793a69 WebCore::FontPlatformData::platformIsEqual(WebCore::FontPlatformData const&) const + 25 (FontPlatformDataCocoa.mm:68)
2   com.apple.WebCore             	0x00000001134c5420 WTF::HashTableAddResult<WTF::HashTableIterator<WebCore::FontPlatformData, WTF::KeyValuePair<WebCore::FontPlatformData, WTF::RefPtr<WebCore::Font, WTF::DumbPtrTraits<WebCore::Font> > >, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::FontPlatformData, WTF::RefPtr<WebCore::Font, WTF::DumbPtrTraits<WebCore::Font> > > >, WebCore::FontDataCacheKeyHash, WTF::HashMap<WebCore::FontPlatformData, WTF::RefPtr<WebCore::Font, WTF::DumbPtrTraits<WebCore::Font> >, WebCore::FontDataCacheKeyHash, WebCore::FontDataCacheKeyTraits, WTF::HashTraits<WTF::RefPtr<WebCore::Font, WTF::DumbPtrTraits<WebCore::Font> > > >::KeyValuePairTraits, WebCore::FontDataCacheKeyTraits> > WTF::HashMap<WebCore::FontPlatformData, WTF::RefPtr<WebCore::Font, WTF::DumbPtrTraits<WebCore::Font> >, WebCore::FontDataCacheKeyHash, WebCore::FontDataCacheKeyTraits, WTF::HashTraits<WTF::RefPtr<WebCore::Font, WTF::DumbPtrTraits<WebCore::Font> > > >::add<std::nullptr_t>(WebCore::FontPlatformData const&, std::nullptr_t&&) + 464 (FontPlatformData.h:174)
3   com.apple.WebCore             	0x00000001134c51c6 WebCore::FontCache::fontForPlatformData(WebCore::FontPlatformData const&) + 102 (FontCache.cpp:342)
4   com.apple.WebCore             	0x00000001134c5139 WebCore::FontCache::fontForFamily(WebCore::FontDescription const&, WTF::AtomicString const&, WebCore::FontTaggedSettings<int> const*, WebCore::FontVariantSettings const*, WebCore::FontSelectionSpecifiedCapabilities, bool) + 217 (utility:753)
5   com.apple.WebCore             	0x0000000112ebef4e WebCore::CSSFontSelector::fontRangesForFamily(WebCore::FontDescription const&, WTF::AtomicString const&) + 270 (CSSFontSelector.cpp:310)
6   com.apple.WebCore             	0x00000001134cd592 WebCore::realizeNextFallback(WebCore::FontCascadeDescription const&, unsigned int&, WebCore::FontSelector*) + 274 (FontCascadeFonts.cpp:150)
7   com.apple.WebCore             	0x00000001134cd204 WebCore::FontCascadeFonts::realizeFallbackRangesAt(WebCore::FontCascadeDescription const&, unsigned int) + 324 (Vector.h:815)
8   com.apple.WebCore             	0x00000001125102a9 WebCore::FontCascadeFonts::primaryFont(WebCore::FontCascadeDescription const&) + 57 (FontCascadeFonts.h:128)
9   com.apple.WebCore             	0x0000000112f295d4 WebCore::StyleResolver::StyleResolver(WebCore::Document&) + 1828 (StyleResolver.cpp:227)
10  com.apple.WebCore             	0x000000011383c2e3 WebCore::Style::Scope::resolver() + 99 (memory:2733)
11  com.apple.WebCore             	0x00000001138425c8 WebCore::Style::TreeResolver::resolve() + 280 (StyleTreeResolver.cpp:66)
12  com.apple.WebCore             	0x0000000112fccdab WebCore::Document::resolveStyle(WebCore::Document::ResolveStyleType) + 747 (memory:2722)
13  com.apple.WebCore             	0x0000000112fcd7f6 WebCore::Document::updateStyleIfNeeded() + 278 (Document.cpp:1971)
14  com.apple.WebCore             	0x000000011338b415 WebCore::DOMWindow::alert(WTF::String const&) + 101 (memory:2713)


Unrelated.

[WebKit Commit Bot]

Comment on attachment 333981 [details]
Patch

Clearing flags on attachment: 333981

Committed r228551: <https://trac.webkit.org/changeset/228551>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Jimmy Wärting]

I'm trying to saving a ReadableStream with Service Worker and Content-Disposition attachment header but it's not working, is this really fixed, patched and released yet?

[youenn fablet]

(In reply to Jimmy Wärting from comment #9)
> I'm trying to saving a ReadableStream with Service Worker and
> Content-Disposition attachment header but it's not working, is this really
> fixed, patched and released yet?

This patch is not fully fixing the issue, it only allows the network process to redo the download by triggering another network request.
Any service worker generated content will not be downloaded.

Please file a new bug for your specific case.

One workaround is to let the page get the data from the service worker (using post message or fetch for instance) and in the page create a download link.
If there is no page, the service worker can also simply create a wrapper page with the data URL to download inside.

[Jimmy Wärting]

(In reply to youenn fablet from comment #10)

Hmm, I thought this issue where about fixing the "real" problem that: quote: "Resources loaded from service workers are not downloadable"

If i should create a new issue, then it would just have the same title...

Resources doesn't have to come from a remote place, they can be generated on the client side as well. I thought this patch where just a temporary solution to save remote files.

> This patch is not fully fixing the issue

hence why i don't think this issue should be "Resolved" yet and why it should be reopen?

> it only allows the network process to redo the download by triggering another network request

Well, that's a bad solution? what if you have a request rate limit? you might pay/request if you use something like RapidAPI and consume someones else api like a video conversion, you upload a large video, it gets canceled, and then the request is processed once again wasting twice as much upload data.

what if you have a one-time download link? very common among Amazons storage. triggering the request again will yield "already consumed"

I'm not going to send the content to the main thread, cuz i'm already doing it in the reverse order, and the reason for why i don't want to create a object url is to save large files in a streaming manner, have a hole issue topic over at https://github.com/jimmywarting/StreamSaver.js/issues/69 regarding this topic

[youenn fablet]

@Jimmy, the remaining work is at https://bugs.webkit.org/show_bug.cgi?id=202142