Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow styles to ask the user for permissions #674

Open
Mottie opened this issue Feb 25, 2019 · 5 comments
Open

Allow styles to ask the user for permissions #674

Mottie opened this issue Feb 25, 2019 · 5 comments

Comments

@Mottie
Copy link
Member

Mottie commented Feb 25, 2019

jhmaster2000 in Discord chat requested that a method be added to ask the user for permissions to set a stylus option. Specificially:

@-stylus-expose-iframes(true)
please add this custom rule so my style can turn on the expose iframes option when its installed
since it relies on it to work and the stupid option is off by default and no one reads the style description telling them to turn it on

@Mottie make it show a pop-up saying " would like to expose iframes" and with the options Allow and Deny

@eight04
Copy link
Collaborator

eight04 commented Feb 25, 2019

Is this a usercss header?

Maybe it will be better to add an include function targeting frames?

@-moz-document frame-url-prefix("https://github.com", "example.com") {
  /* code will be applied to
  
  * frames
  * the URL of the frame must start with `https://github.com`
  * the domain of the top window must be `example.com`
  */
}

@Mottie
Copy link
Member Author

Mottie commented Feb 25, 2019

I don't think we should change the usercss spec for this since it is extension specific. So I thought it would work inside a comment block.

Having it work as a @-moz-document seems like the same situation. Non-Stylus extensions would need to support the frame-url-prefix. And since @-moz-document isn't supported any more (FF 61+), we should avoid extending that at rule any more.

Do you have any input on this enhancment @narcolepticinsomniac and @tophf?

@eight04
Copy link
Collaborator

eight04 commented Feb 25, 2019

I thought expose iframes is already a Stylus-only option?

An advantage of using a new function is that we can analyze the code at compile time so we don't have to actually expose the domain to the HTML DOM. Which means the style works regardless of the expose iframes option.

If we want to avoid adding a new function, we can introduce a @frames-only header e.g.

/* ...
@frames-only example.com
... */
@-moz-document url-prefix("https://github.com") {
  // ...
}

The downside is that it applies to the entire style. You can't configure it for individual sections.

If we want to implement some requirable permissions, we may have to change the flow of style update.

@tophf
Copy link
Member

tophf commented Feb 25, 2019

@expose-top-url-in-iframes main.site.com, another.site.com to enable the behavior on the specified top sites. An editable list of these sites is shown in the options. Each entry has a link to its style (except for manually added entries) shown to the right, for example. When a style adds a new site on update we ask for a confirmation and until that the site is toggled off in the list; removing a site on update doesn't require a confirmation.

OTOH the option was implemented just because it was the easiest solution. While a proper one seems to be a new CSS document function proposed by eight04 because it doesn't compromise security and it allows for a really targeted approach so that the styles are injected only into the iframes on the specified top sites. With this approach there will be no need to ask for permissions or maintain the abovementioned list.

@narcolepticinsomniac
Copy link
Member

As long as the global pref remains in its current state, I'm not gonna lobby for or against anything else particularly hard. I really like the global attributes, and I use them for all kinds of stuff.

we can introduce a @frames-only header

Very cool idea, but not being able to limit it to sections kinda sucks. I almost see this as a separate type of functionality, similar, but pretty different.

@expose-top-url-in-iframes main.site.com, another.site.com

Also very cool, more targeted approach to how it was originally implemented. I've always thought the necessity for user consent was overkill, but I get where you guys are coming from, and it's a good place.

That said, I absolutely hate the idea of any kinda popup or browser alert confirmation anywhere, whether it's within the page, or any of our internal pages. If we go this route, and a confirmation is deemed necessary, I'd suggest a small "allow or decline" dismissible confirmation injected in the iframes themselves. We could stick our icon in it to make sure it catches the users' attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants