On 09/02/2017 12:03 PM, Gijs Kruitbosch wrote: > On 01/09/2017 20:06, Emilio Cobos Álvarez wrote: > Can you elaborate on what you mean by "content pages" in this context?
In general I mean "exposed to web authors". > I'm asking because I think the following things are true: > > - Firefox UI is increasingly using in-content pages (ie content that > loads in browser tabs) to "do stuff". This applies to network error > pages, the preferences, the add-on manager, but also things you might > spend less time thinking about like the "new tab" page. > - From a security hardening perspective, we would like to avoid those > pages having system principal as much as possible (ie ideally they are > unprivileged, 'even' if they're using an about: URI) > - Those pages quite regularly need to use OS-specific styling, and > especially on Windows we sometimes do different things depending on > whether the user is using a high contrast theme (which isn't something > we currently expose to web content outside of the media queries etc.) > - Even besides the browser pages that are using these, there are > bindings we load on "normal" content pages (especially our default > controls for <video> and <audio>) that have styling that expects these > media queries to work. Yup, we already have special filtering to enable some stuff for chrome URIs only. videocontrols.css is loaded from a chrome:// URI already, for example, so I it has access to some features that normal web pages don't have access to. I suspect using the same filter would just work for the other use cases you're mentioning (as long as the stylesheet is loaded from a chrome:// URI, we can expose stuff to it without exposing it to normal author stylesheets). Even if for some reason it wouldn't, it wouldn't be hard to make it work for about: pages other than about:blank, for example (though I suspect it's not going to be necessary to add the special-case). > I remember that when we started doing some of this restricting for other > parts of our CSS/Layout implementation, there were some issues with how > we determine what counts as "content" and what counts as "chrome". How > will that be done here, and will the usecases above continue to work? I'm not aware of the background on this (I'd be curious to know about it though). But as I said above I suspect the existing filtering mechanism we already have will work, or can be made to work without much effort. -- Emilio _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
