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)
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]
Reporter | ||
Comment 1•10 years ago
|
||
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.
Reporter | ||
Comment 2•10 years ago
|
||
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
Reporter | ||
Comment 3•10 years ago
|
||
Josh, can you think of why this seems to happen only in e10s mode?
Flags: needinfo?(josh)
Reporter | ||
Updated•10 years ago
|
Component: Networking → DOM
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(josh)
Resolution: --- → DUPLICATE
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•