Open
Bug 1510386
Opened 6 years ago
Updated 2 years ago
switching between Firefox Nightly/Beta and Release Firefox causes network protocol errors on Release Firefox
Categories
(Core :: Networking, defect, P3)
Tracking
()
NEW
People
(Reporter: dandromb, Unassigned)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: - Install Firefox (stable) Release edition and Nightly edition on the same computer - Use Firefox Nightly - (then exit Nightly) - Use stable Release Firefox (on the same Firefox profile as was used with Nightly) - Visit certain sites (e.g. Gmail) Actual results: Certain sites (including Gmail) give network errors: Corrupted Content Error The site at https://mail.google.com/mail/u/0/ has experienced a network protocol violation that cannot be repaired. The page you are trying to view cannot be shown because an error in the data transmission was detected. • Please contact the website owners to inform them of this problem. Expected results: Release and Nightly should be able to co-exist on the same profile without showing network errors. Nightly should ideally handle this is in a way that doesn't cause issues for Release Firefox on the same profile, or on the other hand, Release Firefox should better handle what Nightly is doing.
Reporter | ||
Comment 1•6 years ago
|
||
Workaround is to refresh profile using about:support on Release Firefox, or to only use Nightly. (I am not sure where Beta plays into all this. Haven't tried it on Beta yet.) I do understand that Nightly is for more-unstable changes, so I'm not really worried about this, but figured there should be a bug for this. It's a little confusing at first, so it's more reassuring if it's a known issue.
Reporter | ||
Comment 2•6 years ago
|
||
Workaround 2: Reload without cache (e.g. "Ctrl + Shift + R")
Reporter | ||
Comment 3•6 years ago
|
||
This does, in fact, happen the same way with Beta as with Nightly.
Reporter | ||
Updated•6 years ago
|
Summary: switching between Firefox Nightly and Release Firefox (with a shared Firefox profile) causes network protocol errors on Release Firefox → switching between Firefox Nightly/Beta and Release Firefox causes network protocol errors on Release Firefox
Comment 4•6 years ago
|
||
I have confirmed this behavior on Windows 10 and Ubuntu 16. I have set this bug's component as (Core) Networking. I hope this is correct. If not, please set a better component. Also, this issue occurs on both Nightly-Release and Beta-Release combinations, so I will assume it is present on all three version. Thank you for your contribution!
status-firefox63:
--- → affected
status-firefox64:
--- → affected
status-firefox65:
--- → affected
Component: Untriaged → Networking
Product: Firefox → Core
Updated•6 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•6 years ago
|
||
I think this ought to be prevented by bug 1455707, but it would still be nice to have some sort of "clear the cache if it's using a newer format" mechanism. I'm also wondering what exactly has changed between versions to cause this issue.
Comment 7•6 years ago
|
||
There is another workaround described in bug 1495275: unregister the service worker for Gmail.
Comment 8•5 years ago
|
||
(In reply to Valentin Gosu [:valentin] from comment #5) > I think this ought to be prevented by bug 1455707, but it would still be > nice to have some sort of "clear the cache if it's using a newer format" > mechanism. I'm also wondering what exactly has changed between versions to > cause this issue. I was able to reproduce the problem and clearing the http cache doesn't fix the error. Removing storage/default/https+++mail.google.com in the profile directory fixes it. I cannot see what's wrong from the log, maybe Honza can read something from it.
Flags: needinfo?(michal.novotny) → needinfo?(honzab.moz)
Comment 9•5 years ago
|
||
(In reply to Michal Novotny [:michal] from comment #8) > I was able to reproduce the problem and clearing the http cache doesn't fix > the error. Removing storage/default/https+++mail.google.com in the profile > directory fixes it. I cannot see what's wrong from the log, maybe Honza can > read something from it. It seems this is a service-worker problem. AFAIK SW cache is backed by a necko cache entry. So if the SW format changes, and can't be parsed any more, there's an error in gmail. I doubt we'd see it in the necko logs - I suspect the mismatch will occur in the child process.
Comment 10•5 years ago
|
||
(In reply to Michal Novotny [:michal] from comment #8) > Created attachment 9030199 [details] > log > > (In reply to Valentin Gosu [:valentin] from comment #5) > > I think this ought to be prevented by bug 1455707, but it would still be > > nice to have some sort of "clear the cache if it's using a newer format" > > mechanism. I'm also wondering what exactly has changed between versions to > > cause this issue. > > I was able to reproduce the problem and clearing the http cache doesn't fix > the error. Removing storage/default/https+++mail.google.com in the profile > directory fixes it. I cannot see what's wrong from the log, maybe Honza can > read something from it. The channel's intercepted and redirected to InterceptedHttpChannel (supposedly). no logs for that. filed 1513889.
Flags: needinfo?(honzab.moz)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•