1384957 - Gmail fails to reconnect; then no other tab can load gmail

Status: RESOLVED DUPLICATE of bug 1390503

(Core :: Networking, defect)

Description

[Ted Campbell [:tcampbell]]

I've been having a sporadic issue where Gmail loses connection and then no other content process is able to load gmail. This is occuring on Win10 64-bit nightly.

Typically this is when I sleep my laptop and wake it on a different network. The gmail tab reflows normally, but says it is trying to reconnect and never succeeds.

When this is happening, no other content process can access gmail (or even google.com). Other domains still load fine. When trying to load google.com, the stop/refresh button animation completes, but the URL is restored to previous page and no navigation happens.

I managed to catch in debugger once when it happened and tried to follow the AsyncOpen request between content and parent processes. At some point when I unfroze all processes, the browser was working again. Some timeout must have triggered as I was holding processes frozen.

I wonder if this is necko related?

Will add more details as bug happens again.

Comment 1

[Kershaw Chang [:kershaw]]

If possible, could you try to capture the HTTP log when you see this problem?

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

BTW, could you also provide the build id of your nightly?

Thanks.

Comment 2

[Honza Bambas (:mayhemer)]

Probably a bug 1380896?

Comment 3

[Ted Campbell [:tcampbell]]

BuildID  20170727100347

Thanks for the link for HTTP logging. Will capture next time. It's about once a week.

My problems didn't seem to go away with page refreshes, but will pay attention next time.

Comment 4

[Honza Bambas (:mayhemer)]

Please see bug 1380896 as well, this might be a duplicate.

Comment 5

[Ted Campbell [:tcampbell]]

Attachment: Screenshot of devtools network after failing to load

Here is a screenshot of after it fails to load in a new tabs with the devtools network manager active.

(The bogus time I've reported as bug 1384679)

Comment 6

[Ted Campbell [:tcampbell]]

I don't see the |Unable to run script because scripts are blocked internally.  (unknown)| message in my browser log.  This seems different from Bug 1380896, but it may be same underlying problem. Will watch for it.

Comment 7

[Ted Campbell [:tcampbell]]

Attachment: http_log.txt-main.7012

Here is the network log.

My STR seems to be:
- Open gmail on office wifi
- Sleep laptop
- Open laptop on home wifi

Refreshing does not resolve. Closing all gmail tabs doesn't resolve.

Tab was on inbox when I slept computer, and after waking I was able to open one email before stopped working.

Comment 8

[Ted Campbell [:tcampbell]]

After a while (a minute?), gmail starts loading again. Perhaps a connection was closed on it's own. Is it possible we aren't detecting dead connection when our IP changes and the remote end closes?

Comment 9

[Ted Campbell [:tcampbell]]

My issue is very likely a result of the TCP FastOpen experiments of Bug 1377004 and Bug 1363372.

Comment 10

[Dragana Damjanovic [:dragana]]

Ted, thanks for the log.

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to Ted Campbell [:tcampbell] from comment #7)
> Created attachment 8891061 [details]
> http_log.txt-main.7012

about:network late started logs are very likely useless here...

Comment 12

[Ted Campbell [:tcampbell]]

Fair enough. Hopefully Bug 1385116 solves this since it is easier to track. I can try next week to reproduce this in a contained way so that I can capture a full HTTP log. Currently I've been running in to it after full days of work on my main profile and I'd rather not build HTTP logs of that.

Comment 13

[Ted Campbell [:tcampbell]]

Sorry, I screwed up and didn't see the logs included all my auth cookies. Hiding this bug and invalidating all my sessions now =\

Comment 14

[Honza Bambas (:mayhemer)]

(In reply to Ted Campbell [:tcampbell] from comment #13)
> Sorry, I screwed up and didn't see the logs included all my auth cookies.
> Hiding this bug and invalidating all my sessions now =\

you could only hide the attachment.

Comment 15

[Daniel Veditz [:dveditz]]

(In reply to Honza Bambas (:mayhemer) from comment #14)
> you could only hide the attachment.

You and I can, but the reporter can't. Just did that.

Comment 16

[Shian-Yow Wu [:swu]]

I've experienced it these days with nightly on Linux.  The HTTP log captured by 2017-08-17 nightly was e-mailed to Dragana.

Comment 17

[Honza Bambas (:mayhemer)]

(In reply to Shian-Yow Wu [:swu] (56 Regression Engineering support) from comment #16)
> I've experienced it these days with nightly on Linux.  The HTTP log captured
> by 2017-08-17 nightly was e-mailed to Dragana.

It's the same issue that led me to filing bug 1389772.

Comment 18

[Dragana Damjanovic [:dragana]]

swu's issue is the same as bug 1389772. We could confirm that from the log.

Comment 19

[Dragana Damjanovic [:dragana]]

I got the log that was attached to this bug and I can confirm that this is the same issue as bug 1386719.

A work around for that issue landed in bug 1389079.

There was a small issue with patch in bug 1389079 that was fixed in bug 1390503.

I will mark this bug a dup of 1390503.

Comment 21

[Dragana Damjanovic [:dragana]]

Also bug 1381256 is the same issue as this one and it is confirm that it has been fixed.

Comment 22

[Dragana Damjanovic [:dragana]]

(In reply to Dragana Damjanovic [:dragana] from comment #19)
> I got the log that was attached to this bug and I can confirm that this is
> the same issue as bug 1386719.
> 
> A work around for that issue landed in bug 1389079.
> 
> There was a small issue with patch in bug 1389079 that was fixed in bug
> 1390503.
> 
> I will mark this bug a dup of 1390503.

This comment was talking about the original issue, the issue the reporter of this bug had. (not swu's issue). Sorry for a confusion.

Comment 23

[Ted Campbell [:tcampbell]]

Ah, nice work tracking down that they were in fact the same issue.