Closed Bug 1146158 Opened 10 years ago Closed 10 years ago

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

Categories

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

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1141332

People

(Reporter: ehsan.akhgari, Unassigned)

References

Details

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]
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.
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?
Flags: needinfo?(annevk)
Summary: Assertion failure: (progressMax == -1) || (progress <= progressMax) (unexpected progress values) when reloading trained-to-thrill in e10s mode → Assertion failure: (progressMax == -1) || (progress <= progressMax) (unexpected progress values), followed by Content Encoding Error when reloading trained-to-thrill in e10s mode
Josh, can you think of why this seems to happen only in e10s mode?
Flags: needinfo?(josh)
Component: Networking → DOM
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(josh)
Resolution: --- → DUPLICATE
Ah, nice!
Flags: needinfo?(annevk)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.