mrbkap found a race condition when we create the desktop notification object.
Comment on attachment 682707 [details] [diff] [review] patch I'm not sure that this can actually race, but the early return in the if (!GetOwner()) case can definitely cause crashes. It's pretty hairy to reference count an object in its constructor, so this seems a lot saner in general.
Attachment #682707 - Flags: review?(doug.turner)
Attachment #682707 - Flags: review?(doug.turner) → review+
Note to blocking-basecamp triagers: this is a very low-risk correctness bug that could prevent child-process crashes in certain edge cases.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
basecamp- but please nom for beta if this is really low risk.
blocking-basecamp: ? → -
Comment on attachment 682707 [details] [diff] [review] patch [Approval Request Comment] User impact if declined: In certain rare cases, content processes could crash when sending desktop notifications. Testing completed (on m-c, etc.): This has been on m-c for a few days. This patch is extremely low-risk, and is easily provably correct via code inspection.
Comment on attachment 682707 [details] [diff] [review] patch [Triage Comment] Very low risk fix that may resolve some B2G instability. Approving for branches.
status-firefox18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
You need to log in before you can comment on or make changes to this bug.