Completely remove TabGroup.
Categories
(Core :: DOM: Navigation, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: farre, Assigned: farre)
References
(Blocks 1 open bug)
Details
Attachments
(8 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1620594 - Part 6: Use AbstractThread::MainThread instead of SystemGroup::AbstractThread. r=nika!
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Assignee | ||
Comment 1•5 years ago
|
||
Added a separate bug for the final stages of TabGroup removal to separate it from the remaining work.
Assignee | ||
Comment 2•5 years ago
|
||
Removing TabGroup directly implies that there is now only one
SchedulerGroup, namely the SystemGroup. Because of this we can at
every point where TabGroup does a dispatch, gets and event target,
etc, switch to SystemGroup instead.
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to default to the SystemGroup.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
DocGroups have also been moved to BrowsingContextGroup.
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Assignee | ||
Comment 5•5 years ago
|
||
Depends on D67631
Assignee | ||
Comment 6•5 years ago
|
||
Depends on D67632
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D67633
Assignee | ||
Comment 8•5 years ago
|
||
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D67635
Updated•5 years ago
|
Updated•5 years ago
|
Comment 10•5 years ago
|
||
This is sort of the same as bug 1561715, so setting same Fission milestone.
Updated•5 years ago
|
Assignee | ||
Comment 11•5 years ago
|
||
There was already an exception already for
mozilla::SchedulerGroup::CreateEventTargetFor, and this code has now
(re)moved to DocGroup as DocGroup::mEventTarget. DocGroup::mEventTarget
is created from DocGroup::Create, which is where the leak shows up now.
Depends on D65936
Updated•5 years ago
|
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4c58ef4b5ed0
https://hg.mozilla.org/mozilla-central/rev/672e860442c3
https://hg.mozilla.org/mozilla-central/rev/7530afa936d5
https://hg.mozilla.org/mozilla-central/rev/22cac5d2d136
https://hg.mozilla.org/mozilla-central/rev/de2dc6c4fe6f
https://hg.mozilla.org/mozilla-central/rev/a5ad3b179c92
https://hg.mozilla.org/mozilla-central/rev/36b0646e8649
https://hg.mozilla.org/mozilla-central/rev/9a9161243d00
Comment 14•5 years ago
|
||
Description
•