Closed Bug 1749241 Opened 4 years ago Closed 4 years ago

Port Firefox control logic from javascript to rust

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Version:
Firefox 95
Type:
enhancement

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: steve, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Inspected firefox source/flow under debugger, discussed conclusions in developer matrix channel to ensure implications robustly understood.

Actual results:

Found firefox application logic to be written in javascript, which is sub-optimal (memory and performance) & forces a requirement for full browser stack to be present in root process as well as content process for regular pages, therefore forcing an excessively complex system architecture whereby content and root processes hold full browser representation - suboptimal.

Here: https://searchfox.org/mozilla-central/source/dom/ipc/BrowserParent.cpp
& here : https://searchfox.org/mozilla-central/source/dom/ipc/BrowserChild.cpp

Expected results:

Firefox control logic should be written in native (suggest rust), thereby removing the need for complete hierarchy duplication across processes as is currently the case.

The objective is remove trusted root browser windows completely. Once that's done, the entire engine top level can simplify, with performance & memory wins across the board. This architectural pivot unlocks future potential both in terms of performance and complexity management.

Current firefox application control logic originates at the intuitively named earlyBlankFirstPaint

https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.jsm#749

Perhaps rename that Firefox_init as step 1.

Suggest two parallel implementations - current & next gen in rust. Current being the default, pivot to next-gen once everyone's happy with it.

Then retire the javascript implementation, ensure no other trusted root browser instances & begin a consideration of how the root process browser view can simplify.

The Bugbug bot thinks this bug should belong to the 'DevTools::Debugger' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Debugger
Product: Firefox → DevTools
Component: Debugger → General
OS: Unspecified → All
Product: DevTools → Firefox
Hardware: Unspecified → All

Suggest shunt as much as is practical to content process browsers. That way javascript rapid development can continue as normal & porting work is kept to the minimum.

Ensure no-script addons are unable to disable necessary trusted content by flagging as such & implement logic as required to deliver this.

The following requires robust resolution to ensure content process diagnostics provide the same level of functionality as trusted root.

https://bugzilla.mozilla.org/show_bug.cgi?id=875210

Diagnostics issue moved here as requested : https://bugzilla.mozilla.org/show_bug.cgi?id=1749249

Minimal essential is Windows only bug resolved. Other platforms receive printf logging as expected, however resolving robustly via new IPC message is of benefit to all - custom presentation & filtering enabled.

This bug report isn't specific enough to be actionable. Generally bugs need to be well targetted, a bug that talked about switching one particular thing from JS to native code for example might pass but there would need to be a good justification for doing so. Switching all of Firefox's JS logic to native code would be a massive multi-year project that likely would not yield enough benefits to be worth it and may well introduce a lot of down-sides.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

Its just too hard.

Not in any way resolved, its strategy header.

Me : "Suggest shunt as much as is practical to content process browsers. "

You: A bug that talked about switching one particular thing from JS to native code for example might pass.

Me: The core control logic, what's left once you've shunted everything to content processes that can be placed there.

You: Switching all of Firefox's JS logic to native code would be a massive multi-year project that likely would not yield enough benefits to be worth it.

Me: Nobody suggested doing that. You've invoked a straw man argument.

You: May well introduce a lot of down-sides.

That's why its an exploratory path. The issues are identified as the work progresses. In the event it genuinely is too hard, abort.

You've just decided performance isn't important. We'll have to agree to disagree.

You've also just decided complexity management isn't important. Again, we'll have to agree to disagree.

(In reply to Steve Williams from comment #8)

Not in any way resolved, its strategy header.

Bugzilla is generally good for specific work items, not long-term strategic changes. We discuss and track those elsewhere.

Me : "Suggest shunt as much as is practical to content process browsers. "

You: A bug that talked about switching one particular thing from JS to native code for example might pass.

Right, so if you have a specific thing that you think it would be good to move then file a bug or start a discussion on that and a productive discussion can be had. Just saying "we should move as much as possible" isn't really helpful.

Me: The core control logic, what's left once you've shunted everything to content processes that can be placed there.

You: Switching all of Firefox's JS logic to native code would be a massive multi-year project that likely would not yield enough benefits to be worth it.

Me: Nobody suggested doing that. You've invoked a straw man argument.

That is what I read from the bug's title and summary, in particular "Firefox control logic should be written in native". I see now that that is somewhat ambiguous, this is where filing specific issues rather than discussing generalities helps.

You: May well introduce a lot of down-sides.

That's why its an exploratory path. The issues are identified as the work progresses. In the event it genuinely is too hard, abort.

You've just decided performance isn't important. We'll have to agree to disagree.

Performance is of course important, but so is development velocity and maintainability. Making some things more performant will often harm the other two so it isn't necessarily always the right choice. But we're just talking in generalities of course. We can't actually figure out what the potential impact of a change is unless we know what we're changing.

(In reply to Steve Williams from comment #9)

You've also just decided complexity management isn't important. Again, we'll have to agree to disagree.

The same arguments apply here.

Bugzilla is generally good for specific work items, not long-term strategic changes. We discuss and track those elsewhere.

Where please.

(In reply to Steve Williams from comment #11)

Bugzilla is generally good for specific work items, not long-term strategic changes. We discuss and track those elsewhere.

Where please.

dev-platform is probably the appropriate newsgroup for something like this.

What you can change is every browser possible to content process. You'll know what you've got better than I. You can measure performance implications of each & if nothing significant shows that direction of travel is a step towards my proposal of removing root process browsers completely.

For example, following discussion on chat, Dale moved a credits or about screen to content. Suggest same procedure with others. Start with the simple ones. Figure out what works & what doesn't. If & when we hit a roadblock or performance implication from doing that, we can discuss what's been discovered.

Unless you object to moving such things to content process as a matter of principle for some reason.

Hi Steve, it's not that editing is disabled, it's that editing is restricted to a specific usergroup. You can request permission to edit bugs and your comments.

For posting bugs I usually try to provide links to the relevant source code, such as on searchfox or phabricator. This increases the chances that somebody will work on your proposed enhancement, since they don't need to go searching through the source code to find what you mean. Of course, you could always submit a patch yourself.

Hi Shane. Yeah, I'll submit our patch & move on I think. You can do all kinds of things but there are only so many hours in the day so I have to time manage to deliver high level vision - the 3d web & a biz over it. Similarly, Mozilla has to do the same with your vision.

We can meet again on the 3d web & at our IPC interface for the low level developers if such things interest you.

I've said my piece, I think I've been understood. Mozilla don't have to do anything you don't want to.

I can't morph gecko codebase to where I think it should be single handedly. I shouldn't even be working on that at all.

You already have a link to our esr 91.4 patch so could work from that. Current 91.5 upgrade is stalled at figuring out how to transition to full screen mode without javascript getting in the way.

I don't think there should be any javascript in mozilla root process. None at all. All key APIs including full screen transition should be present there.

... but what I want & what I get aren't always the same thing :)

Cheers all - difficulties all round.

To progress this bug rather than this end up another chat thread, the next step is to identify the next easiest browser to move to content process & for that to be actioned. I don't know which one that is. Please suggest - that to the room, not you personally unless you have a suggestion.

  • in gecko root process. you have other techs. this is the only one we're currently considering.

Bug title should be "Port Firefox core control logic from javascript to rust".

Apologies, should have been more specific there.

Shunting everything else possible out of the way to content processes before doing so is how we identify what is core & ensures that's a minimum set.

Maybe in the end, there is no core control logic. Maybe all firefox js logic can move to content & all that's required is several functions that are currently in js to be ported to native to get back to where we were which was native applications can interface directly to gecko ("embed").

That being one benefit of the proposal. The other being root process view can then simplify (optimization).

There isn't any productive discussion going on in this bug at this point so let's leave it here and stop filling up people's inboxes.

You need to log in before you can comment on or make changes to this bug.