1284603 - leaks after clicking on an event in google calendar

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P2)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I regularly see the "Leaked URLs" printout at shutdown show google calendar URLs in it.  I've found that I've been able to reproduce the leak with the following relatively simple steps:

 1. set up a clean profile logged in to my google account, set to save tabs at shutdown, with google calendar in a pinned tab and the firefox start page in a non-pinned tab, with the pinned tab active
 2. start up Firefox with this profile
 3. click on an event so the "popup" pops open
 4. click the [X] in the popup
 5. quit Firefox (File -> Quit)

This results in the following printed out at the end of shutdown:

Leaked URLs:
  https://calendar.google.com/calendar/render#main_7
  https://calendar.google.com/calendar/perf
  https://calendar.google.com/calendar/render
nsStringStats
 => mAllocCount:          38390
 => mReallocCount:          860
 => mFreeCount:           38363  --  LEAKED 27 !!!
 => mShareCount:          37423
 => mAdoptCount:           5291
 => mAdoptFreeCount:       5291
 => Process ID: 2269, Thread ID: 140285329734400

...

Leaked URLs:
  https://calendar.google.com/calendar/perf
  https://calendar.google.com/calendar/perf
  https://calendar.google.com/calendar/render
  https://calendar.google.com/calendar/render#main_7
  https://calendar.google.com/calendar/render#main_7
  https://calendar.google.com/calendar/render#main_7
nsStringStats
 => mAllocCount:          92042
 => mReallocCount:         7046
 => mFreeCount:           92002  --  LEAKED 40 !!!
 => mShareCount:          84116
 => mAdoptCount:           5136
 => mAdoptFreeCount:       5134  --  LEAKED 2 !!!
 => Process ID: 2225, Thread ID: 140071844366144

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: child process XPCOM leak log

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: parent process XPCOM leak log

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(but sometimes the child process doesn't leak and only the parent process does)

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack of late HttpChannelChild destruction

When I *don't* see the leaks in the child, I see this stack of rather late destruction of an HttpChannelChild.  I'm guessing this is probably too late to propagate the destruction back up to the parent.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8768147 [details]
stack of late HttpChannelChild destruction

Actually, seems like this is normal.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stacks of the creation of 2 of the 3 leaked URLs in the child

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: explanation of the XMLHttpRequestMainThread in the child

(2 references leaked, both from nsCOMPtrs)

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack of HttpChannelChild creation

This HttpChannelChild never receives any messages, because...

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack of HttpChannelParent creation

The HttpChannelParent doesn't get created until XPCOM shutdown.

Comment 10

[Andrew Overholt [:overholt]]

Ben, is this related to that other HTTPChannelChild (IIRC) bug you're working on?

Comment 11

[Andrew McCreight [:mccr8]]

(In reply to Andrew Overholt [:overholt] from comment #10)
> Ben, is this related to that other HTTPChannelChild (IIRC) bug you're working on?

(bug 1286258)

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

Its possible.  David, can you try reproducing with a build before bug 1277582 comment 43 landed?

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

Oh, that landed after comment 0 here.  So probably not related.

Also, I don't see calendar.google.com running a service worker (at least for my account).

Comment 14

[Andrew Overholt [:overholt]]

FWIW I couldn't reproduce this with 20161020074850 (nightly debug build) on Windows 10.

Comment 15

[Josh Matthews [:jdm]]

Two months ago I had no problems reproducing this leak. Now I cannot, nor could overholt. Any objection to closing this as WORKSFORME?

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, although it might be worth testing if it reproduces with a build from when it was filed to see whether it was a fix on our side or a change on the Google Calendar side.

Comment 17

[Josh Matthews [:jdm]]

I reverted to a revision from around when I last reproduced it, and I can no longer do so. I guess Google Calendar changed in ways that no longer trigger it.