1709425 - [meta] Remove non-Proton branches from our CSS and JS, and Proton prefs

Status: RESOLVED WORKSFORME

(Firefox :: General, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

Once Proton ships, we should remove the non-Proton branches in our CSS and JS that are no longer being used.

We can also then remove the Proton prefs and support for the the -moz-proton selectors.

Comment 1

[VEG]

Could you please clarify when you plan to remove browser.proton.enabled which allows to enable (more or less) old style of the browser? Could you please consider keeping this option at least in the Firefox 91 ESR?

Comment 2

[:Gijs (he/him)]

(In reply to Evgeny from comment #1)

Could you please clarify when you plan to remove browser.proton.enabled which allows to enable (more or less) old style of the browser?

The pref will likely be turned into a no-op during the Firefox 90 cycle.

Could you please consider keeping this option at least in the Firefox 91 ESR?

No, the overhead both in terms of code and in terms of complexity, is significant - so much so that I'm going to split this bug up into a few different dependencies, with a rough schedule as to when each of these is happening, with the goal of making uplifts in the 90 cycle straightforward (instead of having to rebase around conditionals that are there in one branch and not another).

If there are concrete issues you have with the new styling, please file bugs on those insofar as they are not on file already.

Comment 3

[:Gijs (he/him)]

Plan document: https://docs.google.com/document/d/1M_OPsYyIzdyzcP2J7TJAsLMdAUlPS7h2J_AxSAxysqA/edit#

Salient details:

1. From May 17, write and land patches in nightly 90 (no uplift) that remove relevant pref pushes/checks from all test code. This can be split up for the feature prefs and the main pref, and the main pref could be subdivided by directory if there are a lot of accesses, to make the individual patches small and straightforward to test and review.
2. After May 20 (last non-RC beta), land patches that remove relevant pref checks from non-test code. This includes cleaning up CSS code, but not removing the stylo / CSS media queries.
3. After that but before May 27 (soft freeze), land patches that remove cached versions of the prefs (gProton, PanelUI.protonAppMenuEnabled, CustomizableUI.protonToolbarEnabled, etc.), once they’re unused.
4. After June 1, in the 91 cycle, remove the stylo/CSS code and the (now completely unused) preferences. Uplifting this to 90 isn’t needed (though could be done if relman wants it) as conflicts in those files should be trivial to resolve and uplift would be a no-op for 90, as all uses of the prefs will have been removed.

I'll file deps for these, and deps for those deps where appropriate.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 5

[VEG]

The new style can't be "fixed" without throwing it away completely, and it is clear that such proposition won't be accepted because somebody from the management already approved it.

Thanks for clarification that the option will be removed soon and you won't keep it for ESR. I'll stick to the current general version for now then, and probably look for another browser later. Bye.

Comment 6

[Pierre]

Hello,

I'm a simple Firefox user.

Could you not remove that option, please? As many, I like the design how it was and don't want that new thing. The best thing to do is give every one the choice or even better revert to how it was before Firefox 89.

Thank you.

Comment 7

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #3)

Plan document: https://docs.google.com/document/d/1M_OPsYyIzdyzcP2J7TJAsLMdAUlPS7h2J_AxSAxysqA/edit#

So clearly, we did not reach the timeline in this doc. We'll aim to remove the remaining parts in the 91 cycle, to avoid keeping two implementations of everything around for ESR.

Comment 8

[TomK]

Please do NOT remove these properties.

The new Proton design is horrible and wastes way too much screen estate.

Please let users that care for efficient screen usage configure FF to their likings by keeping those properties.

Comment 9

[dazel (she/them)]

are you ruining firefox and ignoring the pleas of the loyal userbase on purpose? why?

Comment 10

[Mike Hoye [:mhoye]]

Hi, all -

While we're always glad for technical feedback in Bugzilla, we're confident in this decision, and intend to stick with it going forward. That said, we're making an effort to move design and high-level product feedback like this over to Ideas.mozilla.org; I hope you'll join and follow the related discussions over there.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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