1623989 - Add MaybeDiscarded-like wrapper for sending BrowsingContext from JS

Status: NEW

(Core :: DOM: Content Processes, task, P3)

Description

[Chris Peterson [:cpeterson]]

This change will help prevent IPC message crashes like bp-1ec19da7-8bfc-4eea-9b7e-c7a030190705 in bug 1563825.

Comment 1

[Andrew McCreight [:mccr8]]

Chris, do you remember how the conclusion was reached that this would help with those crashes? Was that just speculation or is there something in those crash reports that indicates that sending discarded BCs is the issue?

Comment 2

[Chris Peterson [:cpeterson]]

(In reply to Andrew McCreight [:mccr8] from comment #1)

Chris, do you remember how the conclusion was reached that this would help with those crashes? Was that just speculation or is there something in those crash reports that indicates that sending discarded BCs is the issue?

Redirecting needinfo to Nika because I think she suggested this solution. She was writing MaybeDiscarded (bug 1615403) at that time.

The ReceiveRawMessage crash volume in bug 1563824 looks pretty high for a Nightly crash (about 20-40 crash reports/day).

Comment 3

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

From the research that :mccr8 did in that bug by looking at what messages were failing, it doesn't seem like they tend to be failing due to a missing BrowsingContext instance. Many of the messages which are failing seem to be failing for other odd reasons.

IIRC the reason why I thought this might help was due to speculation that the deserialization failures were caused by discarded BCs, yes.

Comment 4

[Neha Kochar [:neha]]

As discussed in the Fission meeting and also mentioned in comment 3, this is most likely not a cause of the crashes and not a major issue right now. We should table this for later.

Comment 5

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

I'm still unsure what the design for this should look like, and it doesn't seem like it's the cause of the specific ReceiveRawMessage crashes we're running into. We might be able to avoid doing this?

:kmag, do you know what design you'd want for this if we did add it or something like it?

Comment 6

[Neha Kochar [:neha]]

Not a beta blocker. kmag and nika continue to discussing the design for this.

Comment 7

[Neha Kochar [:neha]]

Kris, can you add a comment here describing the design that you have thought of?

Comment 8

[Neha Kochar [:neha]]

It is not clear that this is creating any problems as of now, so pushing out to MVP.

Comment 9

[Chris Peterson [:cpeterson]]

This bug is a soft blocker for Fission MVP. We'd like to fix it before our Release channel rollout, but we won't delay the rollout waiting for it.

Comment 10

[Chris Peterson [:cpeterson]]

This is a nice-to-have feature, but doesn't need to block shipping Fission MVP.

Comment 11

[Jens Stutte [:jstutte]]

(In reply to Nika Layzell [:nika] (ni? for response) from comment #5)

I'm still unsure what the design for this should look like, and it doesn't seem like it's the cause of the specific ReceiveRawMessage crashes we're running into. We might be able to avoid doing this?

:kmag, do you know what design you'd want for this if we did add it or something like it?

It seems we moved on for a while without solving this. Does bug 1836195 comment 4 hint we should do this? Do we have a design idea here?

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.