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
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.
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
Attachment #8828138 - Flags: review?(wmccloskey)
Attachment #8828138 - Flags: review?(wmccloskey) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0fdc7261d017 Never set mLastWindowLeft on the Chrome TabGroup, r=billm
You need to log in before you can comment on or make changes to this bug.