1422951 - Add a CSS-parsing WebExtensions API

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P5)

Description

[Boris Zbarsky [:bzbarsky]]

See bug 1035091 comment 110 through bug 1035091 comment 114.  Having an API for this would make a lot of sense.

Comment 1

[Boris Zbarsky [:bzbarsky]]

In terms of how to expose it, there are a few options:

1)  We could add an extensions-only static thing on the CSS interface that takes a string and returns a sequence<CSSRule> or a CSSStyleSheet.

2)  We could make CSSStyleSheet constructible with a string arg from extensions.  This would be a little more complicated but might end up being something that happens on the web eventually anyway.  Or it might not....

Comment 2

[Boris Zbarsky [:bzbarsky]]

There are some open questions about what things should or should not be parseable in this context, of course....

Comment 3

[Emilio Cobos Álvarez (:emilio)]

We have the ReparseStyleSheet stuff already for devtools, I think we can reuse most of it for this... I could take a look at this when I'm not buried in other stuff, I guess... If someone wants to steal it from me that'd be nice too.

Comment 4

[Masatoshi Kimura [:emk]]

I think extensions-only things should be under the `browser` namespace instead of adding a member or a constructor to global interfaces such as CSS or CSSStyleSheet.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK, so there are two separate questions:

1)  What is the API exposed to extensions?
2)  How is that implemented?

In that we could have a browser.something that gets implemented via ChromeOnly things on CSS.

Comment 6

[Andy McKay]

We've got a pretty lightweight process for asking the WebExtensions team about new APIs, so I've added this to that process. If this is a lot of code and you feel a WebExtension peer might not be keen on landing this, it might good to wait for that process to complete before writing too much code.

https://wiki.mozilla.org/Add-ons/Contribute/Triage
https://wiki.mozilla.org/WebExtensions/NewAPIs

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I'll clear the ni? for now. I don't think implementing it is particularly complex, so whenever someone decides on this API, I can implement it.

Comment 8

[Caitlin Neiman [:caitmuenster]]

Hi Boris, this has been added to the agenda for the December 19, 2017 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1KwfTum8Ow5w4afPAOvShpu_d_MNtahhOIqL3-Em9lLc/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 9

[Andrew Swan [:aswan]]

I think browser.something (implemented as suggested in comment 5) makes the most sense if we want this API to be exposed to content scripts since content scripts share the window object with the page in which they are injected.  I'm assuming that makes exposing something as a property on CSS impractical, but would be happy to be corrected.

Boris, can you spell out the questions from comment 2?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Would you be able to join us? 

I don't know yet.  I will be traveling for part of Dec 19, so whether I can join at that time depends on the traffic.  I can try to join if I'm not in a car at the time.  :)

> since content scripts share the window object with the page in which they are injected.

They do, but they see it via Xrays, so we can do different exposure for them and for the page.

> I'm assuming that makes exposing something as a property on CSS impractical

Not at all.  For example, we expose a bunch of properties on HTMLMediaElement to addon content scripts (and in fact only content scripts for addons that have debugger or tab privileges) but not webpages.

I have no personal opinion on whether the api should be browser.something or reached via some other access point.  We should probably put it wherever addon authors are most likely to look for it.

> Boris, can you spell out the questions from comment 2?

Well, for question 1...  Is input a Unicode string or a byte sequence (probably the former?)?.  Is output a CSSStyleSheet, or an array of rules, or are both possibilities?  Do you have to parse full rules (or lists of rules), or can you pass pairs of (property name, property value) somehow?  If the latter, what is returned?  Is there a way to parse just selectors?  If so, what does it return?  Plus of course the question of what the actual integration point or points are (CSS.something, browser.something, something else).

For question 2, it partly depends on the integration points and the API we decide to expose.  The obvious options are to call into Gecko and use its CSS parser, to use the JS fork of the Gecko CSS tokenizer that devtools have, or to reimplement some amount of CSS parsing in JS.  Using the Gecko parser is obviously easier if we have the API return objects that the Gecko parser already knows how to create.

Comment 11

[Caitlin Neiman [:caitmuenster]]

Hi Boris, we weren't quite able to get to this bug on the 9th and it has been added to the agenda for the upcoming triage meeting on January 9, 2018. You are invited to join us! Here's a link to the agenda: https://docs.google.com/document/d/15JYw3L1490dKbr6yTLz1uirH8rfhcSiLJCubSWDlnfs/edit#

Comment 12

[Shane Caraveo (:mixedpuppy)]

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #10)

> > since content scripts share the window object with the page in which they are injected.
> 
> They do, but they see it via Xrays, so we can do different exposure for them
> and for the page.

This seems to be the primary issue.  Otherwise, I'm not clear what the benefit of a new API here is.  What's the use case?  Can teh xray issue be resolved without a new api?

Otherwise, sidebar/page/browser actions (and I'm guessing the background page) should be able to just use existing webapis.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Otherwise, I'm not clear what the benefit of a new API here is.

I don't follow.  The benefit of a new API is to allow extensions to parse CSS that web pages cannot parse, no?

> What's the use case?

Did you read the links in comment 0?

> Can teh xray issue be resolved without a new api?

What do you mean by "the xray issue"?

> should be able to just use existing webapis.

The whole point is, existing webapis don't allow parsing the bits that people want to parse.

Comment 14

[100の人]

I have wrote UserCSSManager that inserts all user styles into all tabs without parsing strings . The reason for not parsing strings and selecting tabs to apply on the JavaScript side is to reduce load and improve speed. However, it stopped working altogether due to Bug 1035091. Currently, I have set layout.css.moz-document.content.enabled to true to prolong the life.

Comment 15

[Gregory Pappas [:gregp]]

Rob, constructable stylesheets landed in Firefox 101. Is this bug still necessary?

Comment 16

[Rob Wu [:robwu]]

I'm marking this bug as WONTFIX because an extension-specific API is unnecessary when there is already a fitting API on the open web platform.

The request from https://bugzilla.mozilla.org/show_bug.cgi?id=1035091#c114 was:

I would very much like, in addons, to have access to a CSS parser that actually parses the CSS that is fed into it and faithfully returns all of the results of that parsing. I am not particularly tied to the “create temporary document, create a style element in there”; that looked like a clever hack, too. A WebExt-exposed function that takes a string of CSS and returns an array of CSSRule would be just fine.

Constructable stylesheets do fit that description. Note that even without the CSSStyleSheet constructor, the requested functionality was already available through a temporary <style> element (in a suboptimal way).

This API is not exposed to (service) workers. A blanket request to port all of CSSOM to workers is not realistic, but we have a more specific feature request about CSS validation in service workers at bug 1580254. Note that Firefox supports event pages in addition to the (in development) service workers, so extensions that really need such functionality can continue to use them.