Closed Bug 1580254 Opened 5 years ago Closed 1 year ago

Support CSS selector validation API from a service worker

Categories

(WebExtensions :: General, enhancement, P2)

enhancement
Points:
5

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: rhill, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: mv3:m3 [mv3-m3] )

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

I was told to open a new issue[1] following my feedback[2] to "Mozilla’s Manifest v3 FAQ".[3] Quoting myself:

Removing access to a DOM would currently break uBlock Origin (“uBO”). uBO uses a DOM element to validate plain cosmetic filters[4] – which are essentially CSS selectors. Having access to the DOM to validate plain cosmetic filters allow uBO to detect and discard or further process invalid cosmetic filters.

Using invalid CSS selectors in an injected stylesheet could entirely break cosmetic filtering where this occurs. There has been instances where CSS selectors valid in one browser were not valid in another browser, or valid in a version of a browser were not valid in another version of the same browser (i.e. CSS4), so detecting invalid CSS selectors has been key to ensure uBO works as intended on any browser while using the same filter lists in all browsers, and without having to burden filter list maintainers about incompatibilities between browsers.

If there is a way to solve this requirement without a DOM that would be great.

I may stumble on other DOM dependencies, the one above is the obvious one I know about.


[1] https://discourse.mozilla.org/t/blog-post-mozillas-manifest-v3-faq/44608/9

[2] https://discourse.mozilla.org/t/blog-post-mozillas-manifest-v3-faq/44608/3

[3] https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/

[4] https://github.com/gorhill/uBlock/blob/ac56aabd7cdf137c5db9e9737112fd6eb96f2511/src/js/static-ext-filtering.js#L71-L108

See Also: → 1580360
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → WebExtensions
Hardware: Unspecified → All
Version: 71 Branch → other
Whiteboard: mv3:m3
Whiteboard: mv3:m3 → mv3:m3 [mv3-m3]
Points: --- → 5
Whiteboard: mv3:m3 [mv3-m3] → mv3:m3 [mv3-m3]
Severity: normal normal → S3 S3
See Also: → 1422951

Bug 1422951 is now wontfix and I quote my own comment.

https://bugzilla.mozilla.org/show_bug.cgi?id=1422951#c14

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.

Since a few months now, I've move from validating the CSS selectors (used as declarative-based DOM filters in uBlock Origin) using the browser API (HTMLElement.querySelector(), HTMLElement.matches()) to the standalone library CSSTree.

Given this, I am not sure the API request here is still relevant.

There are still cases where a valid CSS selector in a different browser or a different version of the same browser could cause issue (this has happened with the :not(...) pseudoclass), but though these cases can create hardship for filter list maintainers, not sure this warrants a new browser API -- theoretically the extension could perform browser version checks.

As far as I am concerned, feel free to close as wontfix.

This feature is covered by event pages, and is a large effort with undefined support in other browsers. When DOM/CSS/etc support is finalized we will reevaluate what tickets are necessary for firefox.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.