[Feature Request] PWA Titlebar Header Color #1772
Comments
Isn't this a big change considering the security? How about collecting a list of use-cases that require modifying DOM, then support them via usercss meta individually? e.g. #674 |
|
What security implications are here? Setting src/href to a URL that can be used for tracking the user? If that's the only one we can forbid setting a URL and/or src/href. |
|
We can start by allowing just this one case i.e. setting a |
According to the syntax, I thought the author will be able to set/create any property on any element. |
|
Well, yes, that was the plan. I just realized that we'll need to exclude all |
|
Yeah, so there is some potential for abuse which we may overlook, so what about this:
|
|
One pro of using individual API is that we can provide clear and precise messages to users when installing a style. For example: Otherwise, it will be |
|
I don't think setting the color property needs a confirmation. I tried to think of other use cases and I remembered just one: overriding !important in a |
I would argue that modifying DOM is a big change that needs a confirmation. CSS, userstyles, and usercss has never been able to modify DOM. Authors have to go for userscript if they need to. That's also why CSS is considered harmless (well, until the css key loger). Even we only modify One use case from me: the viewport meta tag You need this to build styles for mobile. |
As far as I can tell this extension is limited to css injection only.
Unfortunately this means we can't change the color of the title bar for pages installed as apps.
What I'm proposing:
A special tag or selector that would be parsed by stylus & used to overwrite the
<head> ... <meta name="theme-color" content="#XXXXX"> ... </head>tag.I've been able to set this in another extension (custom style script) as js:
but I think allowing unchecked js is definitely a bad idea.
Some sort of controlled access though would be very helpful!
The text was updated successfully, but these errors were encountered: