1146158 - Assertion failure: (progressMax == -1) || (progress <= progressMax) (unexpected progress values), followed by Content Encoding Error when reloading trained-to-thrill in e10s mode

Status: RESOLVED DUPLICATE of bug 1141332

(Core :: DOM: Core & HTML, defect)

Description

[(no longer active)]

STR:

1. In a new profile, load trained to thrill in an e10s window.
2. Reload.

Assertion failure: (progressMax == -1) || (progress <= progressMax) (unexpected progress values), at /Users/ehsan/moz/src/netwerk/protocol/http/HttpChannelChild.cpp:663
#01: mozilla::net::HttpChannelChild::DoOnProgress(nsIRequest*, long long, long long)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x54c1ca]
#02: mozilla::net::InterceptStreamListener::OnProgress(nsIRequest*, nsISupports*, long long, long long)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x54bffc]
#03: mozilla::net::InterceptStreamListener::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x54c5b7]
#04: nsInputStreamPump::OnStateTransfer()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2f4bae]
#05: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2f42bd]
#06: non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2f53cf]
#07: nsInputStreamReadyEvent::Run()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x15ba20]
#08: nsThread::ProcessNextEvent(bool, bool*)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x18d25f]
#09: NS_ProcessPendingEvents(nsIThread*, unsigned int)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1e9c0a]
#10: nsBaseAppShell::NativeEventCallback()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x37c2049]
#11: nsAppShell::ProcessGeckoEvents(void*)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x383cdfd]
#12: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x80681]
#13: __CFRunLoopDoSources0[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x7280d]
#14: __CFRunLoopRun[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x71e3f]
#15: CFRunLoopRunSpecific[/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x71858]
#16: RunCurrentEventLoopInMode[/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x2eaef]
#17: ReceiveNextEventCommon[/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x2e86a]
#18: _BlockUntilNextEventMatchingListInModeWithFilter[/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x2e6ab]
#19: _DPSNextEvent[/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x23f81]
#20: -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x23730]
#21: -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:][/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x383b927]
#22: -[NSApplication run][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x17593]
#23: nsAppShell::Run()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x383d7b7]
#24: XRE_RunAppShell[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x48094fb]
#25: mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x82ade6]
#26: MessageLoop::RunInternal()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7be8e5]
#27: MessageLoop::RunHandler()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7be7f5]
#28: MessageLoop::Run()[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7be79d]
#29: XRE_InitChildProcess[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4808cc7]
#30: content_process_main(int, char**)[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container +0x213b]
#31: main[/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container +0x2232]

Comment 1

[(no longer active)]

In InterceptStreamListener::OnDataAvailable, we use mOwner->GetResponseHead()->ContentLength() as aProgressMax when calling OnProgress(), but that's wrong if the page uses for example gzip content encoding (as trained to thrill does) since the Content-Length header would indicate the size of the gzipped stream.

Comment 2

[(no longer active)]

Passing -1 as the value of aProgressMax as opposed to mOwner->GetResponseHead()->ContentLength() bypasses this error, and then we get a Content Encoding Error page, indicating that we're trying to gunzip the body of the request which has already been gzipped.

I think the real issue here is that when the service worker does a cache.addAll, the underlying fetch decodes the data, but leaves the Content-Encoding header intact, and when we .respondTo() with the cached entry, we end up synthesizing the decoded body, and then the browser attempts to decode it again because it sees the Content-Encoding header.

I'm not sure what the right behavior here is, and I can't find anywhere in the spec where this is described.  Anne, is this somehow covered by the spec?

Comment 3

[(no longer active)]

Josh, can you think of why this seems to happen only in e10s mode?

Comment 5

[(no longer active)]

Ah, nice!