Update selectors crate to 0.25, and enables :has and :is selectors.

[Lymia]

This is a (very minor) breaking change to the API because it adds a new field to the Select iterator in order to add caching for :nth-child.

If this is not wanted, don't pull the last commit da1d495407d5e8b5801172e1061db528fe9e0ffa.

[rillian]

Thanks! I don't see any benchmarks. Do you have numbers for how much the selector cache helps?

[Lymia]

I don't and it might take some thought as to how to construct one. From what I understand, it only matters for selectors that contain :nth-child(x) anyways, which... I'm not sure is the most common selector to care about being fast. It'd be completely legitimate to just leave out, tbh.

[Lymia]

Running on an AMD Framework 13 with a Ryzen 7 7840U:

parse: test_data/real_world/vec_rustdoc.html
                        time:   [16.768 ms 16.864 ms 16.971 ms]

select: test_data/real_world/vec_rustdoc.html / p
                        time:   [446.73 µs 453.60 µs 461.04 µs]

select uncached: test_data/real_world/vec_rustdoc.html / p
                        time:   [480.22 µs 483.68 µs 487.34 µs]

select: test_data/real_world/vec_rustdoc.html / p:has(a)
                        time:   [495.69 µs 499.97 µs 504.66 µs]

select uncached: test_data/real_world/vec_rustdoc.html / p:has(a)
                        time:   [547.53 µs 553.19 µs 559.00 µs]

select: test_data/real_world/vec_rustdoc.html / p + p
                        time:   [452.18 µs 457.92 µs 466.39 µs]

select uncached: test_data/real_world/vec_rustdoc.html / p + p
                        time:   [498.54 µs 516.75 µs 542.44 µs]

select: test_data/real_world/vec_rustdoc.html / p:nth-child(4n+1)
                        time:   [501.90 µs 507.47 µs 513.52 µs]

select uncached: test_data/real_world/vec_rustdoc.html / p:nth-child(4n+1)
                        time:   [563.07 µs 568.15 µs 573.56 µs]

select: test_data/real_world/vec_rustdoc.html / p:nth-of-type(4n+1)
                        time:   [494.85 µs 518.08 µs 546.73 µs]

select uncached: test_data/real_world/vec_rustdoc.html / p:nth-of-type(4n+1)
                        time:   [551.41 µs 582.28 µs 631.73 µs]

parse: test_data/real_world/rust_wikipedia.html
                        time:   [9.9531 ms 9.9872 ms 10.024 ms]

select: test_data/real_world/rust_wikipedia.html / p
                        time:   [247.07 µs 250.44 µs 254.54 µs]

select uncached: test_data/real_world/rust_wikipedia.html / p
                        time:   [271.24 µs 274.19 µs 277.87 µs]

select: test_data/real_world/rust_wikipedia.html / p:has(a)
                        time:   [251.25 µs 252.65 µs 254.23 µs]

select uncached: test_data/real_world/rust_wikipedia.html / p:has(a)
                        time:   [284.42 µs 291.99 µs 302.83 µs]

select: test_data/real_world/rust_wikipedia.html / p + p
                        time:   [246.15 µs 247.80 µs 249.60 µs]

select uncached: test_data/real_world/rust_wikipedia.html / p + p
                        time:   [271.21 µs 273.11 µs 275.26 µs]

select: test_data/real_world/rust_wikipedia.html / p:nth-child(4n+1)
                        time:   [251.70 µs 253.96 µs 256.77 µs]

select uncached: test_data/real_world/rust_wikipedia.html / p:nth-child(4n+1)
                        time:   [396.74 µs 399.24 µs 402.05 µs]

select: test_data/real_world/rust_wikipedia.html / p:nth-of-type(4n+1)
                        time:   [251.21 µs 254.23 µs 258.04 µs]

select uncached: test_data/real_world/rust_wikipedia.html / p:nth-of-type(4n+1)
                        time:   [403.99 µs 408.67 µs 413.81 µs]

Strangely, I'm observing that the cache increases performance for even selectors that shouldn't need to use the cache. I tested with LTO turned on, and that didn't help, so it's not some inlining-related issue. I'm not sure why.

[rillian]

Thanks for adding benchmarks! Seems like a modest speed up for the expected cases? I'm just trying to balance this against the scary warning about crossing the streams with SelectorCache instances. I'm glad you added it, but it would be nice to somehow tie them to the document so they're harder to interchange in the public api.

[rillian]

version 0.5 please, to avoid cargo audit warnings.

[Lymia]

Gah. My IDE betrayed me.

[Lymia]

Thanks for adding benchmarks! Seems like a modest speed up for the expected cases? I'm just trying to balance this against the scary warning about crossing the streams with SelectorCache instances. I'm glad you added it, but it would be nice to somehow tie them to the document so they're harder to interchange in the public api.

Now that I think about it and reading through the code, I don't think it's accurate. The only time it'll cause errors if you mutate a node such that it is still the same OpaqueElement, but, e.g. has different siblings or a different parent. Since, then it may be a different nth child index in two different queries, but the result is cached anyways.

I'll edit the documentation to be more specific.

[Lymia]

After looking at the generated assembly, I think I do have a satisfying explanation for why the cache helps even when :nth-child() isn't used, anyways. Allocating the cache means zeroing the stack space for 6 HashMaps, and also running the Drop (since it can't statically prove nothing is allocated), and that adds up over all the elements in a document. Unfortunately, the API no longer lets you pass None in place of the nth index cache, which presumably would remove that difference.

[Lymia]

There is also an active fork of selectors that is more updated: https://lib.rs/crates/parcel_selectors

I'm investigating it right now too. This would go all the way to cssparser 0.33

Edit: It'd be a LOT more work, because Selector as best I can tell in parcel_selectors takes a borrowed str instead of an owned String.
Edit 2: And it only implements parsing :has and not matching it. nvm, that fork would be a maintenance nightmare, devs only care about whether it parses not whether it works.

[Lymia]

Any update on this PR? The current version should have all the reviews addressed.

[rillian]

Thanks for you patience. I'm away this week, but will follow up when I get back.

[rillian]

@Lymia Unfortunately I'm not longer with Brave, so I won't be able to merge this. Hopefully someone else will take over maintenance.

[thomaseizinger]

@antonok-edm Hope you don't mind the tag. You appear to be working on other Rust projects within brave. Any chance we can get this (and some of the other dependency updates) merged? Thank you 🙏

[antonok-edm]

@thomaseizinger not sure if you're aware, but just to make sure - we do have separate *-speedreader tags in this repo tracking releases of the crate that are used in Brave Browser. There's a little bit of complication since the dependencies used by the *-speedreader releases need to (for the most part) match those used in the browser. In particular, those releases are using selectors 0.24.

Anyways, with regards to this PR and increasing the selectors version - @DJAndries do you have any concerns about this change going into the main branch? Do we have a plan for unifying the main branch with the Brave-specific releases?

[DJAndries]

Anyways, with regards to this PR and increasing the selectors version - @DJAndries do you have any concerns about this change going into the main branch? Do we have a plan for unifying the main branch with the Brave-specific releases?

There are no plans to use releases based off the main branch in the browser for the foreseeable future, so I have no concerns with merging these changes.

[thomaseizinger]

@thomaseizinger not sure if you're aware, but just to make sure - we do have separate *-speedreader tags in this repo tracking releases of the crate that are used in Brave Browser.

No, I wasn't aware, sorry!

I came here because kuchikiki is pulled in quite deep into my dependency tree via tauri-build from the latest crates.io release.

My goal is to deduplicate (and eliminate outdated) dependencies across my dependency tree and this is one of them :)

A new release to crates.io would be much appreciated once the dependency bumps are in. Let me know if I can help prepare that!

Edit: As far as I can tell from the diff, this bump is a non-breaking change and can therefore be a patch-release? That would be awesome as I can then update right away :)

[Lymia]

It's a breaking change in a single place, unfortunately. Plus, 0.25 is no longer the latest selectors, and it might be possible to go all the way to 0.28. I'd have to investigate that though to see if it's viable.

[thomaseizinger]

It's a breaking change in a single place, unfortunately. Plus, 0.25 is no longer the latest selectors, and it might be possible to go all the way to 0.28. I'd have to investigate that though to see if it's viable.

Ah I see, it is the field added to the iterator, right? In that case, could we split this from the dependency bump and release a patch version with just that? I am happy to help in preparing PRs etc to make that possible.