Closed Bug 1480198 Opened 2 years ago Closed 2 years ago

Construct all nsDocShell objects within a BrowsingContext

Categories

(Core :: DOM: Core & HTML, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla64
Fission Milestone M4
Tracking Status
firefox64 --- fixed
firefox65 --- fixed

People

(Reporter: nika, Assigned: farre)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

No description provided.
Priority: -- → P2
Transferring to Andreas
Assignee: nika → afarre
Blocks: 1495659
Since nsDocShell is no longer created when nsComponentManagerImpl is
on the stack we now expose leaks tracked in Bug 1495659.

Depends on D7400
Attachment #8998548 - Attachment is obsolete: true
Blocks: 1496722
These are only showing up in some WPT tests, right? This change will apply to all LSan tests, and this is a very broad change.

You should instead use the very nice per-directory setup jgraham created for LSan suppressions in WPT tests. For instance:
https://searchfox.org/mozilla-central/source/testing/web-platform/meta/websockets/__dir__.ini
QA Contact: overholt
QA Contact: overholt
Add the property lsan-max-stack-depth to enable configuring how many
stack frames we allow LSANLeaks to record.
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a0702430e839
Check for allowed patterns deeper in LSAN stack. r=jgraham
https://hg.mozilla.org/integration/autoland/rev/3f53bdf6763d
Suppress leaks with nsDocShell::Create on the stack. r=mccr8
Attachment #9013555 - Attachment description: Bug 1480198 - Suppress leaks with nsDocShell::Create on the stack → Bug 1480198 - Suppress leaks with nsDocShell::Create on the stack.
https://hg.mozilla.org/mozilla-central/rev/a0702430e839
https://hg.mozilla.org/mozilla-central/rev/3f53bdf6763d
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/13495 for changes under testing/web-platform/tests
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7afa638dc547
[wpt PR 13495] - [Gecko Bug 1480198] Check for allowed patterns deeper in LSAN stack., a=testonly
Pushed by james@hoppipolla.co.uk:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d5ffc2c0617
[wpt PR 13495] - [Gecko Bug 1480198] Check for allowed patterns deeper in LSAN stack., a=testonly
https://hg.mozilla.org/mozilla-central/rev/9d5ffc2c0617
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
I believe :farre has not landed the actual core of this bug yet. Re-opening & ni? to confirm with :farre
Status: RESOLVED → REOPENED
Flags: needinfo?(afarre)
Resolution: FIXED → ---
Yes, only preparatory patches landed.
Flags: needinfo?(afarre)
Depends on: 1500869
Attachment #9013554 - Attachment description: Bug 1480198 - Construct nsDocShell objects inside BrowsingContext → Bug 1480198 - Construct nsDocShell objects inside BrowsingContext.
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5da3c0dad67a
Construct nsDocShell objects inside BrowsingContext. r=peterv
https://hg.mozilla.org/mozilla-central/rev/5da3c0dad67a
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Depends on: 1504989
Component: DOM → DOM: Core & HTML

Retroactively moving fixed bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to an appropriate Fission Milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Fission Milestone: --- → M4
You need to log in before you can comment on or make changes to this bug.