Enable context paint for MozillaOnline extensions
Categories
(Core :: SVG, task)
Tracking
()
People
(Reporter: hectorz, Assigned: hectorz)
References
Details
Attachments
(1 obsolete file)
That is, an extension whose id ends with "@mozillaonline.com". We would like our toolbar buttons to follow user selected themes.
Such ids are restricted on AMO 1.
Comment 1•4 years ago
|
||
The solution in bug 1404568 doesn't work for you?
If not, why can't you use the existing permitted extension id endings of @mozilla.com or @mozilla.org
See also bug 1394579 for an alternative suggestion to adding additional mozilla extension ids
Assignee | ||
Comment 2•4 years ago
|
||
Hi :longsonr,
Thanks for your comment.
(In reply to Robert Longson [:longsonr] from comment #1)
The solution in bug 1404568 doesn't work for you?
I think that means "dark" vs. "light", it certainly works, but we would like to be able to follow the theme more closely.
If not, why can't you use the existing permitted extension id endings of @mozilla.com or @mozilla.org
We have existing extensions and their ids were decided years ago.
See also bug 1394579 for an alternative suggestion to adding additional mozilla extension ids
Yes, it would be the ideal solution, but I'm not seeing much progress there.
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Comment 4•4 years ago
|
||
(In reply to Hector Zhao [:hectorz] from comment #2)
See also bug 1394579 for an alternative suggestion to adding additional mozilla extension ids
Yes, it would be the ideal solution, but I'm not seeing much progress there.
This did come up recently also for the multi-account-containers line extension (see mozilla/multi-account-containers#2046), we (from the Add-ons team) would prefer if we could remove those checks on the addon ids in the future (possibly not a far future) and in the short run try to avoid adding more.
I've just attached a draft patch to Bug 1394579, so that we may increase the chance to unblock that patch instead, and in the end the resulting patch doesn't seem that much more complex than the one attached here.
How that sounds to you? would it be ok for you if we double-check if we can aim for that instead?
Assignee | ||
Comment 5•4 years ago
|
||
Hi Luca,
(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #4)
This did come up recently also for the multi-account-containers line extension (see mozilla/multi-account-containers#2046), we (from the Add-ons team) would prefer if we could remove those checks on the addon ids in the future (possibly not a far future) and in the short run try to avoid adding more.
I understand.
I've just attached a draft patch to Bug 1394579, so that we may increase the chance to unblock that patch instead, and in the end the resulting patch doesn't seem that much more complex than the one attached here.
How that sounds to you? would it be ok for you if we double-check if we can aim for that instead?
Fixing the other bug instead would definitely address my needs, thanks!
Comment 6•4 years ago
|
||
Instead of keeping wasting time to keep a mechanism working that is only available to "privileged" extension, couldn't you decide for a "open" API for this? How about just exposing the current "icon color" as it is used. Maybe make it a new color value exposed with the "theme" API?
Currently it is a nightmare to get a "nice looking" icon in Firefox:
https://github.com/M-Reimer/undoclosetab/blob/master/iconupdater.js
And Mozilla keeps breaking this. Latest problem is that it seems to be possible to have a "light" and a "dark" variant in one theme and Firefox does not communicate the "dark" colors:
https://github.com/M-Reimer/undoclosetab/issues/92
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
WONTFIX given progress in bug 1394579.
Description
•