1332095 - Crash in mozilla::dom::TabGroup::Join

Status: RESOLVED FIXED

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

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-ca433545-65bc-4355-b84e-84af22170115.
=============================================================

Seen while looking at nightly crash stats. Crashes started with 20170105030229 build: http://bit.ly/2ja6WJf.

Possible regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=57ac9f63fc6953f4efeb0cc84a60192d3721251f&tochange=f13abb8ba9f366c9f32a3146245adf642528becd

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Just from taking a quick look at the code, I think that this bug could be caused by the fact that mLastWindowLeft is not being treated differently on the Chrome TabGroup. 

I'll throw together a patch which changes the code to not set mLastWindowLeft on the chrome TabGroup and breaks the cycles some other way.

Comment 2

[Nika Layzell [:nika] (ni? for response)]

Attachment: Never set mLastWindowLeft on the Chrome TabGroup

I haven't tested this yet (doing a try push now), and I'm not completely sure this will fix the problem, but it seemed like a bad idea for us to set mLastWindowLeft on the Chrome TabGroup, as more windows can join that TabGroup at any time.

In order to avoid the reference cycle due to this, I also change mEventTargets on the chrome TabGroup to hold references to the main thread instead of a DispatcherEventTarget, which means that there are no cycles present. I am not sure if this is an OK thing to do.

I also don't know how to reproduce the problem, so there is no test :-/.

MozReview-Commit-ID: K2jLCuTUTSd

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0fdc7261d017
Never set mLastWindowLeft on the Chrome TabGroup, r=billm

Comment 4

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/0fdc7261d017