Resources loaded from service workers are not downloadable
Created attachment 333981 [details] Patch
<rdar://problem/37497961>
<rdar://problem/37592202>
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
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
(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.
Comment on attachment 333981 [details] Patch Clearing flags on attachment: 333981 Committed r228551: <https://trac.webkit.org/changeset/228551>
All reviewed patches have been landed. Closing bug.
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?
(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.
(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
@Jimmy, the remaining work is at https://bugs.webkit.org/show_bug.cgi?id=202142