A WebExtension API to inject custom CSS into chrome
Categories
(WebExtensions :: Untriaged, enhancement)
Tracking
(Not tracked)
People
(Reporter: kolan_n, Unassigned)
Details
With userChrome.css is being phased out as a
a relic from the XUL era
a better way to customize browser interface is needed. It is proposed to creart a new API similar to tabs giving access to chrome. This way it would be possible to recreate some functionality of ClassicThemeRestorer by injecting css rules based on settings set via checkboxes rather than commented-out rules in userChrome.css.
|
||
Updated•6 years ago
|
|
||
Comment 1•6 years ago
|
||
Would this cover a pref replacement for userChrome and userScript?
(In reply to macfan from comment #2)
With userChrome.css is being phased out
where do you know this from?
From the experience with XUL add-ons, I believe.
At first it was "We're just adding WebExtension support, we're not going to remove XUL add-ons"
Then it became "We're not going to remove XUL add-ons support until WebExtension API will cover XUL add-ons functionality"
And finally "We're going to remove them anyway. And we won't add your favorite customization feature into the browser or the webext API, WONTFIX"
And all that hell with add-on signing in the official builds... It all comes from the political decisions, really. But I won't get into that.
Would this cover a pref replacement for userChrome and userScript?
IDK if it will fully cover. What is userScript? I have not found any docs about that file. If it was injected into main chrome of a window and allowed some adding elements and event listeners, I guess the proposed API should cover it too.
With userChrome.css is being phased out
where do you know this from?
https://bugzilla.mozilla.org/show_bug.cgi?id=1541233
Though noone has directly confirmed that the API is phased out, there are some signs that make me feel like that Mozilla desires to get rid of that "legacy".
At first it was "We're just adding WebExtension support, we're not going to remove XUL add-ons"
XPCOM addons are still there. One can create a WebExtension experiment, and from that code one can instantiate XPCOM components. The problem is that they are not allowed to stable builds and into AMO. And that it is hard to persuade Mozilla to include the designed and implemented API into the browser even if it solves a real problem plaguing some extensions. As you have already noted, all of these issues are not technical, but political.
|
||
Updated•6 years ago
|
Marked as dupe, but it is not quite, this but also suggests to allow injecting not only CSS, but also JS.
|
|
||
Comment 7•6 years ago
|
||
(In reply to KOLANICH from comment #6)
Marked as dupe, but it is not quite, this but also suggests to allow injecting not only CSS, but also JS.
There are other bugs that can be duped to but running chrome-privileged JS from webextensions is a hard no.
|
||
Updated•6 years ago
|
Description
•