1495275 - Corrupted Content Error for gmail

Status: RESOLVED DUPLICATE of bug 1510386

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

Description

[seeni0424]

Attachment: Screenshot from 2018-09-30 09-02-18.png

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.

Comment 1

[Michal Novotny [:michal]]

Please, provide HTTP log. See https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 2

[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.

Comment 3

[Selena Deckelmann :selenamarie :selena]

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 '[e-mail]' with the contents.

Comment 4

[Marion Daly [:mdaly]]

Yaron, can you take a look?

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 6

[Yaron Tausky [:ytausky]]

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. :-)

Comment 7

[Yaron Tausky [: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.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 9

[Yaron Tausky [:ytausky]]

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.

Comment 10

[Yaron Tausky [:ytausky]]

Handing over to :tt since I don't know IndexedDB.

Comment 11

[Tom Tung [:tt, :ttung]]

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.

Comment 12

[Tom Tung [:tt, :ttung]]

(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

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 14

[Tom Tung [:tt, :ttung]]

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.

Comment 15

[Tom Tung [:tt, :ttung]]

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

Comment 16

[Tom Tung [:tt, :ttung]]

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

Comment 17

[Tom Tung [:tt, :ttung]]

It seems this is the same issue as bug 1510386.

Comment 18

[Tom Tung [:tt, :ttung]]

(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.

Comment 19

[Valentin Gosu [:valentin] (he/him)]

(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.

Comment 20

[Graham Perrin]

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.

Comment 21

[bart]

(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.

Comment 22

[heartnotes3]

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.

Comment 23

[Tom Tung [:tt, :ttung]]

(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

Comment 24

[Mitch]

Running Waterfox 56.2.7.1, have been experiencing this for about 2 weeks.

Web console displays
Failed to load ‘https://mail.google.com/mail/u/1/#inbox’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘TypeError: NetworkError when attempting to fetch resource.’.

Browser console displays
While creating services from category 'profile-after-change', service for entry 'Notification Telemetry Service', contract ID '@mozilla.org/notificationTelemetryService;1' does not implement nsIObserver.
PAC file installed from
An error occurred during a connection to mail.google.com:443.

SSL peer reports incorrect Message Authentication Code.

Error code: <a id="errorCode" title="SSL_ERROR_BAD_MAC_ALERT">SSL_ERROR_BAD_MAC_ALERT</a>
(unknown)
Failed to load ‘https://mail.google.com/mail/u/1/#inbox’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘TypeError: NetworkError when attempting to fetch resource.’. sw.js:140:107
Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt” id=“key_toggleReaderMode” browser.xul
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xul
TelemetryStopwatch: requesting elapsed time for nonexisting stopwatch. Histogram: "PLACES_AUTOCOMPLETE_1ST_RESULT_TIME_MS", key: "null" TelemetryStopwatch.jsm:363
Failed to load ‘https://mail.google.com/mail/u/1/#inbox’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘TypeError: NetworkError when attempting to fetch resource.’. sw.js:140:107
PAC file installed from
Content Security Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive. (unknown)
Content Security Policy: Couldn’t process unknown directive ‘worker-src’ (unknown)
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified (unknown)
Content Security Policy: Directive ‘frame-src’ has been deprecated. Please use directive ‘child-src’ instead. (unknown)
Content Security Policy: This site (https://bugzilla.mozilla.org) has a Report-Only policy without a report URI. CSP will not block and cannot report violations of this policy. (unknown)
Content Security Policy: The page’s settings observed the loading of a resource at self (“script-src https://bugzilla.mozilla.org 'nonce-yxuDR1J1B5LyD0jlli2HUguXpw6dwICg9OOMH8BEuP5mArw9' 'unsafe-inline' https://www.google-analytics.com”). A CSP report is being sent. Source: onsubmit attribute on FORM element.

Ignore the PAC file, connected on a proxy, deleted proxy information. The error occurs on both my home network without a proxy and my organisation internet with a proxy.

I have the same version of waterfox on my desktop at home, but haven't attempted to open gmail from there, will attempt soon.

Hope this helps

Comment 25

[Tom Tung [:tt, :ttung]]

(In reply to Mitch from comment #24)
Hi Mitch, I am sorry about what you are experiencing and thank you for providing more information. It seems that there are more than one causes and symptoms for this error, so I have a few questions for you:

Have you ever downgraded your Waterfox? I ask that because a downgrade might have some impact on your profile/storage (there is a storage version difference 56 and 57)

If you hard refresh (command/control + R) the page or unregister the service worker from the about:serviceworkers page, does that help to get away from this issue?

Comment 26

[Tom Tung [:tt, :ttung]]

Andrew, just in case you miss comment 24. This seems to be related to the expiration of CSP or network authentication stuff?

Comment 27

[Graham Perrin]

Reports from users of Waterfox (not supported by Mozilla), in the Waterfox help area:

https://redd.it/9wfdrn

– includes some troubleshooting information, and a link to this bug 1495275.

There are other posts in the help area, essentially duplicates of https://redd.it/9wfdrn

I assume that an eventual fix for Firefox might be ported to Waterfox.

Looking back, I might summarise as follows:

• https://github.com/MrAlex94/Waterfox/issues/581 was broad-ranging (not specific to Gmail) and considered fixed by https://github.com/MrAlex94/Waterfox/commit/7e991d57e06e9b0d52229c7062def23a8ce50158 https://github.com/MrAlex94/Waterfox/commit/d82c62b756b3ff9b250357e0357428a8e8c35f0f and https://github.com/MrAlex94/Waterfox/commit/f874dbfaac9344f25e2f363dd3064fbac25d1bbf
• https://github.com/MrAlex94/Waterfox/issues/694 was essentially a duplicate of https://github.com/MrAlex94/Waterfox/issues/581
• https://github.com/MrAlex94/Waterfox/issues/794 is Gmail-specific and was closed by the opening poster, I added a post-closure link to this bug 1495275

Given the Firefox 56.0 basis of Waterfox 56.0 (we're now at 56.2.71) and the possibility/likelihood of differences in behaviours between Waterfox and Firefox, I should probably encourage reports from users of Waterfox to continue in Waterfox areas (not under this Firefox bug).

Tom Tung [:tt, :ttung], thoughts?

TIA

Comment 28

[Tom Tung [:tt, :ttung]]

(In reply to Graham Perrin from comment #27)

Given the Firefox 56.0 basis of Waterfox 56.0 (we're now at 56.2.71) and the possibility/likelihood of differences in behaviours between Waterfox and Firefox, I should probably encourage reports from users of Waterfox to continue in Waterfox areas (not under this Firefox bug).

Tom Tung [:tt, :ttung], thoughts?

TIA

Thanks for providing more information and collecting them!

The original issue here is probably due to the downgrade and can be fixed by un-registering the service worker and removing network cache. Besides, after enabling profile per channel [1], that issue should be mitigated.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1455707

Honestly, it hard for now to say whether it's Firefox issues (so that having impacts on WaterFox) or WaterFox-only issue from information I got. It looks like both of them are involved. Hopefully, some of them should be fixed by bug 1454400 in Firefox 60. (But, there are some users using Firefox 6x still hit the issue based on https://github.com/MrAlex94/Waterfox/issues/581).

Just FYI, we are going to have a big architecture change for service workers on Firefox 67 or 68 (bug 1231208).

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

While I understand that there may be some presumed overlap between Waterfox and Firefox in this case, the corrupted content error is very much a catch-all for all manners of direct and indirect errors. Any Waterfox-related issues will need to be handled in Waterfox forums unless the bug reproduces on a current Firefox nightly.

I'm obsoleting the waterfox related comments and will obsolete this comment to avoid complicating the bug.

Comment 30

[Tom Tung [:tt, :ttung]]

(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