Closed Bug 1646648 (tb-fission) Opened 4 years ago Closed 3 years ago

[meta] Thunderbird e10s/fission support

Categories

(Thunderbird :: General, task, P2)

Tracking

(thunderbird_esr78 wontfix)

RESOLVED FIXED
86 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: mkmelin, Unassigned)

References

Details

(Keywords: meta)

Firefox has put a lot of effort into e10s support, and Fission (see bug 1451850).

https://wiki.mozilla.org/Electrolysis
https://wiki.mozilla.org/Project_Fission

Sooner or later we'll have to support running Thunderbird under e10s. Once we get to there, it would likely show nice performance improvements too.

This is the bug to track Thunderbird related e10s/fission work. Pointers certainly welcome.

Priority: -- → P2

When I started looking at this recently, I didn't get too far, but I also was just looking for the feasibility of some things.

The main thing to start testing this is flip the browser.tabs.remote.autostart preference to true. Flipping extensions.webextensions.remote might be a reasonable thing to do at the same time, as you can then see the separate "ThunderbirdCP WebExtensions" process in task manager and know something is working.

At the moment, flipping the pref breaks the message pane, and also content tabs (probably some chrome tabs as well).

I'd suggest starting off by trying to get the preference enabled, but remote content disabled probably everywhere - certainly the message pane, maybe the content tabs as well. You could probably at least get WebExtensions into their own process by doing that. Not significantly important, but a step in the right direction.

I think at one time, you could set a "remote" flag on the browser element, though I'm not sure if that's just the initial state of the element.

It looks like there's a way of setting if various protocols can be remote or not, so maybe that's worth investigating:

https://searchfox.org/mozilla-central/rev/eef39502e08bcd3c40573c65a6827828dce4a032/toolkit/modules/E10SUtils.jsm#426

In any case I'd really suggest ignoring the mail protocols first (except to get them working in non-remote mode) and going for the content tabs - Firefox has done this there already, so there's likely to be code to look at and similarities to use, that will also likely help with working on the message pane later.

I suspect for the message pane, there might be a lot of work to do, due to how everything injects into it. I have some ideas about that, but lets discuss when we're a bit further down the road.

Note that in-process extensions is deprecated and we do not actively run unit tests with e10s + in-process extensions with Firefox (in browser/). We do currently run toolkit/ code with in-process extensions because Firefox still uses in-process extensions on Android, but we will likely remove the extensions.webextensions.remote=false pref at some point (bug 1613141). So if you want to migrate to e10s/Fission, I highly recommend to set extensions.webextensions.remote = true.

I don't often look at Thunderbird code, but recently I did see code that is incompatible with e10s/Fission/out-of-process extensions: code in the main (parent) process should not directly access properties from content windows in the child process. But this code does that, and it should be refactored: https://searchfox.org/comm-central/rev/972f93b7d372cd8b6ef349f4e7aff2707b7d4595/mail/components/extensions/parent/ext-mail.js#35-65

Depends on: 1660186

Current status: I'm trying to get a page to load in the message pane, but it crashes. I've traced the problem back to here – I don't know why the pipe is closed, or even what pipe we're talking about. There's also a problem here where sharedData doesn't have a lot of the things I expect it should have, including ChildSingletonActors. This could be related to the first problem, I don't know.

Can you post the patch on a separate bug? I doubt we'd get everything fixed in a couple of patches, and having a patch that people can look at might give ideas.

Depends on: 1667294
Depends on: 1668432
Depends on: 1668457
Depends on: 1671301
Blocks: 1641577
Depends on: 1681438
Depends on: 1683783
Depends on: 1683785
Depends on: 1683787
Depends on: 1687436
Depends on: 1687612
Regressions: 1687747
Regressions: 1687835
Regressions: 1687847
No longer regressions: 1687835
Regressions: 1688248
Depends on: 1688474

We need to decide which regressions will block releasing beta 86.

For reference: first build to include this was 2021-01-20.

Regressions: 1688551
Regressions: 1688567

(In reply to Wayne Mery (:wsmwk) from comment #5)

We need to decide which regressions will block releasing beta 86.

Probably a good idea to hold the beta for a few days.
The printing bug (bug 1688248) is kind of bad so I would wait at least on that.

Depends on: 1688248
No longer depends on: 1688248
Regressions: 1688474
No longer depends on: 1688474
Regressions: 1689042
No longer regressions: 1689042
Regressions: 1687937
Regressions: 1689461
Regressions: 1689506
Regressed by: 1674954
No longer regressed by: 1674954
Regressions: 1674954
Depends on: 1690042
Regressions: 1690176
No longer depends on: 1690042
Regressions: 1690042
Regressions: 1690141
Regressions: 1690514
Depends on: 1690826
No longer depends on: 1690826
Regressions: 1690826
Regressions: 1690987
Regressions: 1689985
Regressions: 1690900
Regressions: 1691935

Is there a plan for which TB version this might likely be shipped?

It's been in betas since 86, which was the base work.
Over time we will make more use of it.

Target Milestone: --- → 86 Branch
No longer regressions: 1674954
Regressions: 1721272
Regressions: 1706911

This should've been closed months ago.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Regressions: 1734161
Regressions: 1780977
You need to log in before you can comment on or make changes to this bug.