Deprecate browser_style in MV3
Categories
(WebExtensions :: Frontend, enhancement, P2)
Tracking
(firefox114 fixed)
Tracking | Status | |
---|---|---|
firefox114 | --- | fixed |
People
(Reporter: robwu, Assigned: robwu)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete, Whiteboard: [wecg][addons-jira])
Attachments
(1 file)
The browser_style
feature is supposed to allow extensions to inherit the "native browser style" from the browser. In practice, the extension.css stylesheet is unmaintained and does not keep up with changes from the browser (e.g. bug 1421652), partly because any change to the stylesheet has potential to affect many others.
Besides not living up to the promise of matching the browser style, the stylesheet also increases the complexity of supporting dark theme (e.g. without the browser_style
dark theme support would be as easy as adding <meta name="color-scheme" content="light dark">
, now some additional CSS is needed to undo the browser_style
, e.g. as seen in this example).
We should deprecate browser_style
. MV3 was released relatively recently (bug 1801291), so deprecating sooner than later would minimize impact. Chrome's counterpart (chrome_style
) was also dropped from MV3 (https://crbug.com/973157).
browser_style defaults to true for the following, which means that every extension will have the styles by default:
options_ui.browser_style
(default true) - source: schemas/manifest.json - Most significant.sidebar_action.browser_style
(default true) - source: schemas/sidebar_action.json
browser_style
is available and defaults to false for the following, which means that these pages are only affected if the extension opted in with "browser_style": true
.
action
/browser_action.browser_style
(default false) - source: schemas/browser_action.jspage_action.browser_style
(default false) - source: schemas/page_action.json
Global styles
The only "global" styles are as follows (with annotations added by me). Out of all CSS rules, box-sizing: border-box
and display: flex
have the most potential to alter the layout significantly.
html,
body {
background: transparent; /* already default (Canvas) */
box-sizing: border-box; /* defaults to padding-box, may affect some layout */
color: #222426; /* defaults to #00000 (black) (CanvasText) */
cursor: default; /* defaults to auto */
display: flex; /* defaults to block; affects layout */
flex-direction: column; /* defaults to row; affects layout */
font: caption; /* affects font; but not fixed in practice */
margin: 0; /* overrides body { margin: 8px; } */
padding: 0; /* already default */
user-select: none; /* user unfriendly; defaults to user-select: auto */
}
body * {
box-sizing: border-box; /* affects layout */
text-align: start; /* already default */
}
.browser-style and other class names
extension.css
also enables styling for elements with the .browser-style
class name and some other class names starting with panel
:
- https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/browser/components/extensions/extension.css#28-552
- https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/browser/components/extensions/extension-mac.css#5-15
- Documentation: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/user_interface/Browser_styles#firefox_panel_components
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
•
|
||
Editing title to more accurately reflect that the initial step is to deprecate.
My current plan is as follows:
- this bug: Firefox 114 (or 113 if approved): no behavioral changes, only log messages.
- bug 1830710: Firefox 115: change defaults for options_ui.browser_style and sidebar_action.browser_style from true to false (in MV3).
- bug 1830711: Future: drop support for
browser_style: true
in MV3, by default. - bug 1830712: Far future: remove code and prefs supporting
browser_style: true
in MV3.
The behavior can be controlled through the following preferences:
extensions.browser_style_mv3.supported
; initially true, ultimately false (in bug 1830711).extensions.browser_style_mv3.same_as_mv2
; initially true, then false (in bug 1830710).
Assignee | ||
Comment 2•2 years ago
|
||
This patch has no observable changes, other than printing deprecation
messages when browser_style is effectively true in MV3.
This patch does include the full logic for all stages of the deprecation
process behind prefs, which will follow the schedule described at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1827910#c1.
All combinations of these prefs are fully covered by unit tests in
toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js
The next test tasks confirm the behavior of the current patch:
- browser_style_never_deprecated_in_MV2
- supported_with_browser_style_false
- supported_with_browser_style_true
- supported_with_mv2_defaults
Assignee | ||
Comment 4•2 years ago
|
||
dev-doc-needed:
See initial comment for details and comment 1 for the deprecation plan.
Discourage the use of browser_style
and the reliance on it in:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/user_interface/Browser_styles
If one really depends on the browser_style: true
styles, they can bundle the following stylesheet with their extension:
While probably not interesting, note that there are macOS-specific styles for the .browser-style
class; if an extension is interested in these as well:
Comment 5•2 years ago
|
||
Backed out for causing xpcshell failures in test_ext_browser_style_deprecation.js
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | xpcshell.ini:toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js | browser_style_never_deprecated_in_MV2 - [browser_style_never_deprecated_in_MV2 : 62] Got expected warnings for MV2 extension with browser_style:true. - ["Reading manifest: Warning processing sidebar_action: An unexpected property was found in the WebExtension manifest."] deepEqual []
Assignee | ||
Comment 6•2 years ago
|
||
Test failed on Android because the sidebar_action is desktop-only. I'm going to reland with the adjusted test: https://phabricator.services.mozilla.com/D176811?vs=712282&id=712402#diff-change-oy6TmTwIFdFy
Comment 8•2 years ago
|
||
Backed out for xpcshell failure on test_ext_browser_style_deprecation.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/f4fe5fa3e75417623282441f8a2c0303f04f5659
Log link: https://treeherder.mozilla.org/logviewer?job_id=414657046&repo=autoland&lineNumber=5954
Assignee | ||
Comment 9•2 years ago
|
||
Test failed again on Android because an UnrecognizedProperty is not omitted, but included (without validation), causing the runtime check to run validation for sidebar_action
despite the build not supporting sidebar_action
. I've fixed this by wrapping the runtime check in an additional condition: https://phabricator.services.mozilla.com/D176811?vs=712407&id=712502#C6353775NL1506
I have also filed bug to follow up on this aspect of UnrecognizedProperty, under the second class of problems in bug 1831417.
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
bugherder |
Comment 12•2 years ago
|
||
Description
•