1510386 - switching between Firefox Nightly/Beta and Release Firefox causes network protocol errors on Release Firefox

Status: NEW

(Core :: Networking, defect, P3)

Description

[Dan D (volunteer tester from the community)]

Attachment: Corrupted Content Error

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.

Comment 1

[Dan D (volunteer tester from the community)]

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.

Comment 2

[Dan D (volunteer tester from the community)]

Workaround 2: Reload without cache (e.g. "Ctrl + Shift + R")

Comment 3

[Dan D (volunteer tester from the community)]

This does, in fact, happen the same way with Beta as with Nightly.

Comment 4

[Daniel Bodea [:danibodea]]

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!

Comment 5

[Valentin Gosu [:valentin]]

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

[Tom Tung [:tt, :ttung]]

There is another workaround described in bug 1495275: unregister the service worker for Gmail.

Comment 8

[Michal Novotny [:michal]]

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

Comment 9

[Valentin Gosu [:valentin]]

(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

[Honza Bambas (:mayhemer)]

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