Closed Bug 1495275 Opened Last year Closed 2 months ago

Corrupted Content Error for gmail

Categories

(Core :: DOM: Networking, defect, P2)

62 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1510386

People

(Reporter: seeni0424, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180913170256

Steps to reproduce:

Go to Gmail.com with signed in account


Actual results:

It shows Corrupted Content Error 


Expected results:

It should have loaded a gmail as usual.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Please, provide HTTP log. See https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Flags: needinfo?(seeni0424)
I found some other info. This error is somehow related to service worker bugs. When i unregistered the service worker(sw) the error disappears but this kind of errors never happened on the chrome browsers.
Flags: needinfo?(seeni0424)
Marion - could someone from your team dig into this a bit with someone from Necko? If we can gather a cache directory or create a reproducible test case, that would be extremely useful. 

:seeni0424 -- would you be willing to provide a copy of your cache directory in .zip format? You can email me 'selena@mozilla.com' with the contents.
Flags: needinfo?(mdaly)
Yaron, can you take a look?
Flags: needinfo?(mdaly) → needinfo?(ytausky)
Assignee: nobody → ytausky
If anyone else experiences this, there should be error messages logged to the devtools console that would be invaluable to have screenshotted or copied-and-pasted here, as they will help indicate what underlying problems the gmail ServiceWorker may be experiencing.
I'm looking at this, but a quick attempt to reproduce (registering new account, opening inbox) failed (rather expectedly).
Selena, please let me know if you get more information from :seeni0424; I don't have many leads right now. :-)
Flags: needinfo?(ytausky)
Thanks to :kershaw we do have a lead: it looks like this happens with profiles that were used with nightly and then with release. I'll try to reproduce.
We have a somewhat similar scenario in bug 1503072 reported where a corrupted content error occurred due to a buggy SW and for reasons not yet fully understood, the update mechanism wasn't able to replace the SW.  We're currently most focused on determining why the updates failed to occur on that bug, but there's still the issue of proactively dealing with the error.

The only time the corrupted content UI is useful on a navigation fetch is for a developer debugging the SW.  For normal users it makes sense to fall-back to the normal network path with LOAD_BYPASS_SERVICE_WORKER in effect.

The bigger implementation question is what we do about the existing registration.  In the case of bug 1503072, the SW itself was buggy, and so there was some period of time where immediately unregistering the ServiceWorker would lead to a cycle of:
- navigation FetchEvent dispatched to ServiceWorker, ServiceWorker explodes
- Our migitation fires: SW uninstalled, normal network fetch occurs
- The page loaded from the network re-installs the broken ServiceWorker.  If the SW claims the client, the page may immediately break.
- (user closes page, cycle repeats next time they open a page matching the registration scope)

There's additionally some potential weirdness with this approach thanks to the prefix-based scope matching of ServiceWorkers.  If a site has a valid SW at "/" and a broken SW at "/maps" and we unregister "/maps", "/" will start handling maps URL's again.


Which is to say, that perhaps the thing we should do instead of naively unregistering is:
- Add internal-only flags on the registration that allow us to mark it broken.
- Set the broken flag on any registration that generates a corrupted content error on a navigation fetch and immediately terminate the SW if it has no (other) controlled clients.
- If a registration has "broken" set on it, we always set the LOAD_BYPASS_SERVICE_WORKER flag.  We also adjust the 24-hour soft-update logic to allow checks more frequently so that a fixed SW will be detected more promptly.  We should also consider treating the updateViaCache mode as if it was "imports" if it was set to "all", and perhaps "none" if it was set to "imports", or maybe always just "none".
- We clear the broken flag on a registration when the update algorithm decides to progress to installation and the new ServiceWorker activates.

The rationale here is that we avoid wasteful CPU and bandwidth usage by requiring that the SW has actually changed as well as avoiding clients.claim() allowing the the broken SW to break the page.
Component: Networking: HTTP → DOM: Service Workers
See Also: → 1503072
I reproduced it by using 63.0.1 with my nightly profile and traced through the obfuscated code. At some point in the execution a call to IDBTransaction.objectStore() threw an InvalidStateError, so I assume the problem comes from IndexedDB.
Status: UNCONFIRMED → NEW
Component: DOM: Service Workers → DOM: IndexedDB
Ever confirmed: true
Priority: -- → P2
Handing over to :tt since I don't know IndexedDB.
Assignee: ytausky → shes050117
Thanks for help from :ytausky, I can reproduce it on my desktop (Ubuntu) and record it by rr. I'm not sure if it's the same steps that the reporter had, though.
STR
1. Open current Nightly 65
2. Go to Gmail mailbox and ensure the service worker is registered.
2. Close the Nightly
3. Open another Nightly 63
4. Go into the Gmail mailbox

ps. The workaround is to unregister the registering service worker for gmail

However, I didn't find any warning or error message which is related to IndexedDB among the debug messages from my Debug build.

The most suspicious messages are:
[rr 15897 186181][Child 15897, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/xpcom/io/nsBinaryStream.cpp, line 975                                                              │
[rr 15897 186185][Child 15897, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/xpcom/io/nsBinaryStream.cpp, line 985                                                              │
[rr 15897 186189][Child 15897, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/dom/fetch/ChannelInfo.cpp, line 94
[rr 15897 186193][Child 15897, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/dom/serviceworkers/ServiceWorkerEvents.cpp, line 322

they were printed out right after my Firefox got a Corrupted Content Error and the error code I got for that is:
NS_ERROR_FACTORY_NOT_REGISTERED (0x80040154)

The ChannelInfo object was broken when the executing service worker tried to intercept a request and respond with a response. I suspect the ChannelInfo which had been stored in the mInternalResponse was broken or outdated.

I'm not sure it's a bug in service worker or networking, but it's definitely not related to IndexedDB from the debug messages I got so far.
Status: NEW → UNCONFIRMED
Component: DOM: IndexedDB → DOM: Networking
Ever confirmed: false
(In reply to Tom Tung [:tt] from comment #11)
> I'm not sure it's a bug in service worker or networking, but it's definitely
> not related to IndexedDB from the debug messages I got so far.
I thought all kinds of error would be caught by NS_WARN_IF(NS_FAILED(rv)) in IDB, but :asuth reminded me that they are only for catching unexpected errors.

I will do more investigating by having a breakpoint on https://searchfox.org/mozilla-central/source/dom/bindings/ErrorResult.h#276 as he suggested to see if there are IDB exceptions [1].

[1] https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/IDBRequestBinding.cpp#378
And if it works, maybe try and use `call DumpJSStack()` to capture the JS stack at the call-site in addition to the C++ stack.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I set a breakpoint at EnsureOriginIsInitialized() in the parent process and my rr broke two times before receiving corruptedContentError

$9 = (const nsACString &) @0x7f087a205998: {<mozilla::detail::nsTStringRepr<char>> = {mData = 0x7f08812fdf0c "https://mail.google.com", mLength = 23, mDataFlags = (mozilla::detail::StringDataFlags::TERMINATED | mozilla::detail::StringDataFlags::REFCOUNTED), mClassFlags = mozilla::detail::StringClassFlags::NULL_TERMINATED}, static kMaxCapacity = 2147483633}
#1  0x00007f089a95e063 in mozilla::dom::cache::Context::QuotaInitRunnable::Run() (this=0x7f087a205920) at /home/shes050117/Work/mozilla-central/dom/cache/Context.cpp:438

$10 = (const nsACString &) @0x7f08814c5a38: {<mozilla::detail::nsTStringRepr<char>> = {mData = 0x7f087a9c000c "https://mail.google.com", mLength = 23, mDataFlags = (mozilla::detail::StringDataFlags::TERMINATED | mozilla::detail::StringDataFlags::REFCOUNTED), mClassFlags = mozilla::detail::StringClassFlags::NULL_TERMINATED}, static kMaxCapacity = 2147483633}
#1  0x00007f089b80f87b in mozilla::dom::indexedDB::(anonymous namespace)::OpenDatabaseOp::DoDatabaseWork() (this=0x7f08814c5900) at /home/shes050117/Work/mozilla-central/dom/indexedDB/ActorsParent.cpp:21352

It seems that $9 was triggered by installing the seriveworker script for https://mail.google.com and $10 was triggered by opening a database in IndexedDB.
And then, I saw:

[Child 28708, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/xpcom/io/nsBinaryStream.cpp, line 975
[Child 28708, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/xpcom/io/nsBinaryStream.cpp, line 985
[Child 28708, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/dom/fetch/ChannelInfo.cpp, line 94
[Child 28708, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/shes050117/Work/mozilla-central/dom/serviceworkers/ServiceWorkerEvents.cpp, line 322

[Child 28708, Main Thread] WARNING: A runnable was posted to a worker that is already shutting down!: file /home/shes050117/Work/mozilla-central/dom/workers/WorkerPrivate.cpp, line 1585
[Child 28708, Main Thread] WARNING: Failed to dispatch offline status change event!: file /home/shes050117/Work/mozilla-central/dom/workers/WorkerPrivate.cpp, line 2127

--DOMWINDOW == 2 (0x7f869426cc00) [pid = 28708] [serial = 1] [outer = (nil)] [url = about:neterror?e=corruptedContentErrorv2&u=https%3A//mail.google.com/mail/u/0/%23inbox&c=UTF-8&f=regular&d=The%20site%20at%20https%3A//mail.google.com/mail/u/0/%23inbox%20has%20experienced%20a%20network%20protocol%20violation%20that%20cannot%20be%20repaired.]



From the error message above, I could guessestimate the issue was happened in process 28708.

In child process 28708, I set breakpoints on 
dom/indexedDB/IDBRequest.cpp:296:    aRv.Throw(NS_ERROR_DOM_INVALID_STATE_ERR);
dom/indexedDB/IDBRequest.cpp:366:    aRv.Throw(NS_ERROR_DOM_INVALID_STATE_ERR);
dom/indexedDB/IDBIndex.cpp:163:    aRv.Throw(NS_ERROR_DOM_INVALID_STATE_ERR);
dom/indexedDB/IDBTransaction.cpp:939:    aRv.Throw(NS_ERROR_DOM_INVALID_STATE_ERR);
dom/indexedDB/IDBObjectStore.cpp:1957:    aRv.Throw(NS_ERROR_DOM_INVALID_STATE_ERR);
dom/indexedDB/IDBObjectStore.cpp:2662:    aRv.Throw(NS_ERROR_DOM_INVALID_STATE_ERR);
dom/bindings/ErrorResult.h:276 (this was redirected to objdir/dist/include/mozilla/ErrorResult.h:276)

Note that my testing environment is on Nightly version 63 (509812:7c2b7d3a4665) so the line numbers might be different.

However, my rr didn't break before receiving the corruptedContentError.
I could find InvalidStateError even after trying jsdebugger yesterday. So, I'll try to find the problem based on what I found in my error log before.

(In reply to Tom Tung [:tt] from comment #14)
> [Child 28708, Main Thread] WARNING: 'NS_FAILED(rv)', file
> /home/shes050117/Work/mozilla-central/xpcom/io/nsBinaryStream.cpp, line 975

That's [1], and the cid was:

{m0 = 0x1000400, m1 = 0x0, m2 = 0x1, m3 = {0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x6}}

cid should be class id, and, IIUC, it was stored into the disk by service worker (using DOM Cache).

I suspect that the cid might become invalid during upgrade/downgrade (e.g. a newly created class become invalid in the older version).

In this case, the scenario might be that the service worker had been registered in Nightly 65 and had cached information. Then, an information became invalid since that service worker was using a build in Nightly/Release 63. So that the cid failed to be found.

The confusing part is that I cannot find a class using 0x1000400 as its cid in the searchfox (that service worker was registered and cache information in currently Nightly). I'll figure that out. 

[1] https://searchfox.org/mozilla-central/rev/7f7c353e969e61a6a85201cc8ad3c3de12ac30d8/xpcom/io/nsBinaryStream.cpp#971
I found something interesting with while looking into the unexpected failure in [1]. It failed because the securityInfo object is not recoverable from the serialized string in version 63. 

The interesting thing is that while doing Base64Decode() for recovering serialized and cached string to an object. I found that the same input string in both 63 version and 65 version somehow had different deserialized strings.
The input is: FnhllAKWRHGAlo+ESXykKAAAAAAAAAAAwAAAAAAAAEaphjojH6pBabDSgSnsfLHeAAgAAgAAAAAAAAAAAAAAAAAAAAEAMQFmCjImkVxP+7sgiYWmMt8FvcOXmlQiTNWFiWlrbpbqgwAAAAAAAAPfMIID2zCCAsOgAwIBAgIIRs0YYEw01CQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMcR29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODEwMzAxMzE0MDBaFw0xOTAxMjIxMzE0MDBaMGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgTExDMRgwFgYDVQQDDA9tYWlsLmdvb2dsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQMbL3Z95zYKtUYcWHbsg9o1NJnk3NrQ1gnqh6JgBSyPvDLPiqoo/HqNbzNq0MmO6Se3R9e0SS8kScEDoZbP4kVo4IBZTCCAWEwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgeAMCwGA1UdEQQlMCOCD21haWwuZ29vZ2xlLmNvbYIQaW5ib3guZ29vZ2xlLmNvbTBoBggrBgEFBQcBAQRcMFowLQYIKwYBBQUHMAKGIWh0dHA6Ly9wa2kuZ29vZy9nc3IyL0dUU0dJQUczLmNydDApBggrBgEFBQcwAYYdaHR0cDovL29jc3AucGtpLmdvb2cvR1RTR0lBRzMwHQYDVR0OBBYEFDAIoEPMxqRxZpqC0YZRPJ7eI3qLMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUd8K4UJpndnaxLcKG0IOgfqZ+ukswIQYDVR0gBBowGDAMBgorBgEEAdZ5AgUDMAgGBmeBDAECAjAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnBraS5nb29nL0dUU0dJQUczLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAZgNe/yXd2LDGP7UKC+oLOeYIvWu603nLUazVfAgWl6cJ2gXaPl9uFTvNQ8dfeniAUSlDfr4ZZv0Qk86SHnTRlQ+8xbW44ArDQXLChTHi5+q5RQGaaYw1wtIUINVyJ/icIkjnXhqNt2uwh4DZPNDCeWrZ0XC+wOyVT5SL1DUrnx6RIcDusiBIJFXrbVqvz9Y9Yjb4ZRAZ9oYdJKt104u3hwOrI1Yjs13GIefZVO7KxJTB8E9AyqibQLBQ3KrY3wbycYnMHOReZOOSWJUqebxf/Gvh0CY5dHbxT/5kHmjvz+gcds1URxy1M7pT2OciegmlhrBdkEC4d857pgovROnW3RMBAAQAAAAAAQEAAAAAAAAGeDI1NTE5AAAAEUVDRFNBLVAyNTYtU0hBMjU2AZWfsWVlF0h/q5vYkTvlMZeudM2lzS9HP5b18Lf/9ixoAAAAA2YKMiaRXE/7uyCJhaYy3wW9w5eaVCJM1YWJaWtuluqDAAAAAAAAA98wggPbMIICw6ADAgECAghGzRhgTDTUJDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUwIwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMB4XDTE4MTAzMDEzMTQwMFoXDTE5MDEyMjEzMTQwMFowaTELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2dsZSBMTEMxGDAWBgNVBAMMD21haWwuZ29vZ2xlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAxsvdn3nNgq1RhxYduyD2jU0meTc2tDWCeqHomAFLI+8Ms+Kqij8eo1vM2rQyY7pJ7dH17RJLyRJwQOhls/iRWjggFlMIIBYTATBgNVHSUEDDAKBggrBgEFBQcDATAOBgNVHQ8BAf8EBAMCB4AwLAYDVR0RBCUwI4IPbWFpbC5nb29nbGUuY29tghBpbmJveC5nb29nbGUuY29tMGgGCCsGAQUFBwEBBFwwWjAtBggrBgEFBQcwAoYhaHR0cDovL3BraS5nb29nL2dzcjIvR1RTR0lBRzMuY3J0MCkGCCsGAQUFBzABhh1odHRwOi8vb2NzcC5wa2kuZ29vZy9HVFNHSUFHMzAdBgNVHQ4EFgQUMAigQ8zGpHFmmoLRhlE8nt4jeoswDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR3wrhQmmd2drEtwobQg6B+pn66SzAhBgNVHSAEGjAYMAwGCisGAQQB1nkCBQMwCAYGZ4EMAQICMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwucGtpLmdvb2cvR1RTR0lBRzMuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQBmA17/Jd3YsMY/tQoL6gs55gi9a7rTectRrNV8CBaXpwnaBdo+X24VO81Dx196eIBRKUN+vhlm/RCTzpIedNGVD7zFtbjgCsNBcsKFMeLn6rlFAZppjDXC0hQg1XIn+JwiSOdeGo23a7CHgNk80MJ5atnRcL7A7JVPlIvUNSufHpEhwO6yIEgkVettWq/P1j1iNvhlEBn2hh0kq3XTi7eHA6sjViOzXcYh59lU7srElMHwT0DKqJtAsFDcqtjfBvJxicwc5F5k45JYlSp5vF/8a+HQJjl0dvFP/mQeaO/P6Bx2zVRHHLUzulPY5yJ6CaWGsF2QQLh3znumCi9E6dbdZgoyJpFcT/u7IImFpjLfBb3Dl5pUIkzVhYlpa26W6oMAAAAAAAAEYDCCBFwwggNEoAMCAQICDQHjqTAc/HIGOD+aUx0wDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMTcwNjE1MDAwMDQyWhcNMjExMjE1MDAwMDQyWjBUMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUwIwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAylJL6h7/ziRrqNpyGGjVVl0OSFotNQl2Ws+kyByxqf5TifutNP+IW5+75+gAAdw1c3UDrbOxuaR9KyZ5zhVACu9RuJ8yjHxwhlJLFv5qJ2vmNnpiUNjfmonMCSnrTykUiIALjzgegGoYfB29lzt4fUVJNk9BzaLgdlc8aDF5ZMlu11EeZsOiZCx5wOdlw1aEU1pDbcuaAiDS7xpp0bCdc6LgKmBlUDHP+7MvvxGIQC61SRAPCm7cl/q/LJ8FOQtYVK8GlujFjgEWvKgaTUHFk5GiHqGL8v7BiCRJo0dLxRMB3adXEmliK+v+IO9p+zql8H4p7u2WFvexH6DkkCXgMwIDAQABo4IBMzCCAS8wDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBR3wrhQmmd2drEtwobQg6B+pn66SzAfBgNVHSMEGDAWgBSb4gdXZxwewGoG3lm0mi3f3BmGLjA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnBraS5nb29nL2dzcjIwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5wa2kuZ29vZy9nc3IyL2dzcjIuY3JsMD8GA1UdIAQ4MDYwNAYGZ4EMAQICMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vcGtpLmdvb2cvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBABy3iZbkU+277NuoMgGfLKPNba1CEnezuObJA1JgIHtXJ8YRtT9nDZksW1rKIgrdnrsfS0g/jwI9iyGERR1t9f+saInNZOLW1l5Awo4q9+8U0zakQDD1MhUVknb7fp5T6sJ2/DmtiP5mkibpHMQ4zUn6Q4fwXdZWTYHXf/HC3bBN/sMqbnyfblztYkKZ4fc27hSMLCDjRpdadwPAoMZKiP1AIodyWhjqnKXHWgiM5AWkfbmENV+JNlYOQD0S6Ls1cu2vCFZOsLsuqZvk+x0+C2PIm0uRRGZXwBS0lvDcLFc/UgStlap9TdDyDJ+cQOjWVXO6PN+QywBbIRFnwu0yHt5mCjImkVxP+7sgiYWmMt8FvcOXmlQiTNWFiWlrbpbqgwAAAAAAAAO+MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPLv4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklqtTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzdC9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pazq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCBmTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IHV2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4GsJ0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavSot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxdAfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLgA=

output in 63:

            `>��


output in 65:xe��Dq����I|�(

That looks like an issue, but I'm not sure if it's related to this Corrupted Content Error. I'll check that tomorrow.

[1] https://searchfox.org/mozilla-central/rev/d850d799a0009f851b5535580e0a8b4bb2c591d7/dom/serviceworkers/ServiceWorkerEvents.cpp#321-325
[2] https://searchfox.org/mozilla-central/rev/7f7c353e969e61a6a85201cc8ad3c3de12ac30d8/netwerk/base/nsSerializationHelper.cpp#39-40
Whiteboard: [necko-triaged]
It seems this is the same issue as bug 1510386.
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1510386
(In reply to Tom Tung [:tt, :ttung] from comment #17)
> It seems this is the same issue as bug 1510386.

Hmm, probably not because unregistering a service worker shouldn't be related to network cache.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: DUPLICATE → ---
See Also: → 1510386
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(In reply to Tom Tung [:tt, :ttung] from comment #18)
> (In reply to Tom Tung [:tt, :ttung] from comment #17)
> > It seems this is the same issue as bug 1510386.
> 
> Hmm, probably not because unregistering a service worker shouldn't be
> related to network cache.

Actually, the service worker is backed by the necko cache, so I assume it's the same cause. But I think it ought to be solved in the service worker code, since nothing in the necko cache format changed to cause these issues.
Following this from a Waterfox perspective. (56.2.6 on FreeBSD-CURRENT; last year's 56.0 was based on Firefox 56.0.2.)

A few observations at <https://www.reddit.com/r/waterfox/comments/9wfdrn/-/ecr2enj/> (I shouldn't pollute this Firefox bug with Waterfox noise). Frustratingly I can't make things reproducible.
(In reply to Yaron Tausky [:ytausky] from comment #7)
> Thanks to :kershaw we do have a lead: it looks like this happens with
> profiles that were used with nightly and then with release. I'll try to
> reproduce.

Not in my case. Haven't used this profile with nightly, just with release. Ctrl+F5 temporarily solves it though, till I open a new tab later and access gmail again.

Andrew Sutherland [:asuth]

Where do I find the console devtools?

If anyone else experiences this, there should be error messages logged to the devtools console that would be invaluable to have screenshotted or copied-and-pasted here, as they will help indicate what underlying problems the gmail ServiceWorker may be experiencing.

I don't know how to properly quote things here yet.

(In reply to heartnotes3 from comment #22)

Andrew Sutherland [:asuth]

Where do I find the console devtools?

If anyone else experiences this, there should be error messages logged to the devtools console that would be invaluable to have screenshotted or copied-and-pasted here, as they will help indicate what underlying problems the gmail ServiceWorker may be experiencing.

I don't know how to properly quote things here yet.

You can find your web console on the developer tools. Here is a reference for hot-keys [1]. If you cannot find something useful, you might check the browser console as well. Here is a reference about the hot-keys for it [2].

[1] https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Opening_the_Web_Console
[2] https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Opening_the_Browser_Console

(In reply to Valentin Gosu [:valentin] (he/him) from comment #19)

Actually, the service worker is backed by the necko cache, so I assume it's
the same cause. But I think it ought to be solved in the service worker
code, since nothing in the necko cache format changed to cause these issues.

Since it's the same cause, I'm going duplicate this bug with that one

Status: ASSIGNED → RESOLVED
Closed: 11 months ago2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1510386
Assignee: ttung → nobody
You need to log in before you can comment on or make changes to this bug.