Closed Bug 1294237 Opened 3 years ago Closed 3 years ago

Crash in mozilla::dom::TabChild::RecvSwappedWithOtherRemoteLoader:

Categories

(Core :: IPC, defect, P1, critical)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox50 --- verified
firefox51 --- verified

People

(Reporter: pauljt, Assigned: jhao)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [userContextId][OA][uplift50+])

Crash Data

Attachments

(1 file)

Filing a follow-up bug to 1280105, as this appears to have appeared again. Crash report available

https://crash-stats.mozilla.com/report/index/59acaee0-56c4-4511-adf8-fc4572160810

STR:
1. Create a new container tab
2. Load a url
3. Tear off the tab, so that it creates a new window

Result:
Child process crashes 

Expected:
No crash! A new window opens showing the content.

I verified this on nightly 51.0a1 (2016-08-10).
Sorry, disregard, that *is* my crash report. :)
Looks like the matching SendSwappedWithOtherRemoteLoader call comes from here: http://searchfox.org/mozilla-central/rev/d83f1528dbcb1e837d99cf5b6c36a90b03bf0e77/browser/base/content/browser.js#1144

The code at lines 1121-1126 looks like it's trying to make the user context ID match, but this condition still fails:

http://searchfox.org/mozilla-central/rev/d83f1528dbcb1e837d99cf5b6c36a90b03bf0e77/dom/ipc/TabContext.cpp#181

And the difference I'm seeing between those two OriginAttributes objects is mUserContextId.
Related or duplicate Bug 1290835
Duplicate of this bug: 1290835
Bah :/ I went through mozregression three times just to make sure, all three times bug#1261842 was listed as the culprit. 

11:01.94 INFO: Last good revision: 84b5a1027550faf65534d67dc02372ba09508550
11:01.94 INFO: First bad revision: 80ab1089a326e4a35d32cd6f52ed0194eba89ecf
11:01.94 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=84b5a1027550faf65534d67dc02372ba09508550&tochange=80ab1089a326e4a35d32cd6f52ed0194eba89ecf

11:03.43 INFO: Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1261842
Assignee: nobody → jhao
Hi Mike, would you please review this patch?
Attachment #8780431 - Flags: review?(mconley)
Status: NEW → ASSIGNED
Comment on attachment 8780431 [details] [diff] [review]
Set userContextId when DOMContentLoaded before updateBrowserRemoteness.

Review of attachment 8780431 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8780431 - Flags: review?(mconley) → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c7e5f970ee61
Set userContextId when DOMContentLoaded before updateBrowserRemoteness. r=mconley
Keywords: checkin-needed
Since this is a crash and Test Pilot will probably still be going on in FF 50, we should nominate to uplift to 50.
Whiteboard: [userContextId][OA] → [userContextId][OA[uplift50+]
I'm assuming this isn't a 49 issue?
>> I'm assuming this isn't a 49 issue?

This doesn't seem like it affects fx49. I went through the original STR in comment#0 including other scenarios and couldn't reproduce the tab crashes. I also ran through a debug version of m-b to make sure there weren't any errors being generated through the terminal.

Build Used:

* fx49.0b4 [non-debug], buildId: 20160814184416, changeset: ab7b68014a1e
** https://archive.mozilla.org/pub/firefox/candidates/49.0b4-candidates/build1/mac/en-US/
(In reply to Tanvi Vyas [:tanvi] from comment #11)
> I'm assuming this isn't a 49 issue?

Confirmed - the patches that landed that caused this bug (bug 1261842), is only on Firefox 50+.
https://hg.mozilla.org/mozilla-central/rev/c7e5f970ee61
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Comment on attachment 8780431 [details] [diff] [review]
Set userContextId when DOMContentLoaded before updateBrowserRemoteness.

Approval Request Comment
[Feature/regressing bug #]: Bug 1294237
[User impact if declined]: This is a crash. Containers will be in Test Pilot starting from FF49 and probably going on to FF50 also.
[Describe test coverage new/current, TreeHerder]: No tests for this UI currently.
[Risks and why]: Not much to normal users because containers are pref'd off.
[String/UUID change made/needed]: None.
Attachment #8780431 - Flags: approval-mozilla-aurora?
I won't be able to test/verify this under m-c until bug#1296041 is fixed. Currently, dragging any tab/windows over the tabstrip will crash the entire browser. It's the #2 crash under nightly right now so hopefully it will get fixed soon.

[1] https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=51.0a1&days=7
Comment on attachment 8780431 [details] [diff] [review]
Set userContextId when DOMContentLoaded before updateBrowserRemoteness.

Looking at the crash reports from Nightly51, there have been no instances of it since the fix landed, Aurora50+
Attachment #8780431 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [userContextId][OA[uplift50+] → [userContextId][OA][uplift50+]
Went through verification using the following builds:
* https://archive.mozilla.org/pub/firefox/nightly/2016/08/2016-08-23-03-02-24-mozilla-central/
** FX51.0a1, buildId: 20160823072522, changeset: 052656fc513c

Platforms Used:
* macOS 10.11.6 x64 - PASSED
* Win 10 x64 VM - PASSED
* Ubuntu 16.04.1 LTS - PASSED

Test Cases Used:

* went through the original test case from comment#0
* went through the test case from bug#1280105comment#12 and ensured that tearing tabs off while "Never Remember History" is selected via about:preferences#privacy worked
* tearing off tabs within PB mode
* tearing off tabs that belong to the default container
* tearing off tabs that belong to containers (went through all four containers)
* tearing off tabs using non-e10s tabs
* tearing off container tabs created on OSX when there's no windows opened
* tearing off container tabs ceated via "Hamburger Menu -> Open Container Tabs"
* teating off container tabs created via the "drop down arrow" when there's a lot of tabs opened
* tearing off container tabs created via the right click context menu
* tearing off container tabs after restoring the session via about:home
* tearing off container tabs after restoring the session using "Show my windows and tabs from last time" via about:preferences#general
Went through verification using the following builds:
* https://archive.mozilla.org/pub/firefox/nightly/2016/08/2016-08-24-00-40-01-mozilla-aurora/
** fx50.0a2, buildId: 20160824004001, changeset: a72bfbdf5c9b

Platforms Used:
* macOS 10.11.6 x64 - PASSED
* Win 10 x64 VM - PASSED
* Ubuntu 16.04.1 x64 LTS - PASSED
(In reply to Kamil Jozwiak [:kjozwiak] from comment #20)
> Went through verification using the following builds:
> *
> https://archive.mozilla.org/pub/firefox/nightly/2016/08/2016-08-24-00-40-01-
> mozilla-aurora/
> ** fx50.0a2, buildId: 20160824004001, changeset: a72bfbdf5c9b
> 
> Platforms Used:
> * macOS 10.11.6 x64 - PASSED
> * Win 10 x64 VM - PASSED
> * Ubuntu 16.04.1 x64 LTS - PASSED

Hey Kamil - I believe the origin of https://bugzilla.mozilla.org/show_bug.cgi?id=1280105#c12 
was actually https://bugzilla.mozilla.org/show_bug.cgi?id=1282589#c23 which is Win7

When will this hit Nightly so I can test?
(In reply to Codacoder from comment #21)
> Hey Kamil - I believe the origin of
> https://bugzilla.mozilla.org/show_bug.cgi?id=1280105#c12 
> was actually https://bugzilla.mozilla.org/show_bug.cgi?id=1282589#c23 which
> is Win7
> 
> When will this hit Nightly so I can test?

The fix has landed on all the platforms. You shouldn't be seeing the crashes under Win 7 anymore but please let me know if that's not the case. I also went through the following test cases under a Win 7 x64 VM using the latest m-c [1] and I couldn't reproduce the issue anymore:

* bug#1282589comment#23
* bug#1280105comment#12
* bug#1294237comment#19

The crash rates indicate that the issue has been resolved as well [2]. It looks like the only crashes that are coming in are from builds that are older then bug#1294237comment#14.

[1] Build Used:
* fx51.0a1, buildId: 20160825030226, changeset: 01748a2b1a46
** https://archive.mozilla.org/pub/firefox/nightly/2016/08/2016-08-25-03-02-26-mozilla-central/

[2] https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Adom%3A%3ATabChild%3A%3ARecvSwappedWithOtherRemoteLoader&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#reports
@Kamil - new bug?

I wanted to test using the "Never Remember History" setting to check my original bug[1]. Nightly is not remembering the "Never Remember History" setting and is reverting to "Use custom settings for history" (with seemingly random checkboxes checked/unchecked. Also, it doesn't always ask to restart Nightly after changing the History setting (I believe it should).

I noticed also to use containers, history must be enabled (is that a requirement?). Using a container while testing my original bug: PASS!

Let me know if you think that's a new bug above and I'll file it.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1282589#c23
> Nightly is not remembering the "Never Remember History" setting
> and is reverting to "Use custom settings for history" (with
> seemingly random checkboxes checked/unchecked.

I tried reproducing this with today's nightly on several different platforms, including Win 7 x64 but I couldn't reproduce the problem. Could you please create a new bug and attach as much information as possible including detailed STR?

> Also, it doesn't always ask to restart Nightly after Nightly
> after changing the History setting (I believe it should).

That should be the correct behaviour. Anytime "Never Remember History" is selected under about:preferences#privacy, the user should be prompted to restart the browser for the changes to be applied. I couldn't reproduce this either. Again, could you please create a new bug and add as much information as possible?

> I noticed also to use containers, history must be enabled (is that a
> requirement?). Using a container while testing my original bug: PASS!

Yup, that's correct. The container feature is disabled when "Never Remember History" is being used as it essentially puts firefox into private browsing mode. Because we disable containers under private browsing, this also applies to "Never Remember History". We're going to add a section in the current container sumo page [1] that will let users know that containers are disabled when "Never Remember History" or PB is used. You can follow the progress in bug#1287765comment#13.

There's also bug#1297533 that will hopefully make the prompt that users receive when using "Never Remember History" more intuitive.

[1] https://support.mozilla.org/en-US/kb/containers-experiment
(In reply to Kamil Jozwiak [:kjozwiak] from comment #24)
> > Nightly is not remembering the "Never Remember History" setting
> > and is reverting to "Use custom settings for history" (with
> > seemingly random checkboxes checked/unchecked.
> 
> I tried reproducing this with today's nightly on several different
> platforms, including Win 7 x64 but I couldn't reproduce the problem. Could
> you please create a new bug and attach as much information as possible
> including detailed STR?

https://bugzilla.mozilla.org/show_bug.cgi?id=1298065
Duplicate of this bug: 1301430
You need to log in before you can comment on or make changes to this bug.