You can see the inspector styles for UA rules as above by going to "Settings -> Show browser styles".

So, I guess the extra "rule" is the ::highlight pseudo-element, and we're somehow coming up with matches when you pass it down to InspectorUtils.getCSSStyleRules(element, "::highlight")?

There are two things going wrong:

 * We're parsing ::highlight(foo) even without the pref enabled. That needs to be fixed, see other comments.

• We're not failing to parse ::highlight as a pseudo-element. We need to reject this, this is web-observable via getComputedStyle(element, "::highlight"), which shouldn't return a style.
• We're somehow selector-matching the ::highlight styles? How?

Can you file a bug to make this also apply to modal dialogs? We should show the backdrop styles there.

Let's make this const, since it doesn't change during the lifetime of the object.

This eventually would need to invalidate or so, right?

This eventually would need to invalidate or so, right?

Why would we want to disregard these in high-contrast-mode? For selection it makes sense because we want the "native" selection style. But what's the default style for highlights?

You need to null out aHighlightName otherwise right?

This only gates the DOM API but not the CSS one. So this needs to become a type: RelaxedAtomicBool (because we parse CSS off the main thread), and needs to use rust: true.

Maybe add an is_simple() getter that does the not (is_tree or is_highlight)? You're using that in a couple places.

Definitely needs to check is_pseudo_element_enabled, and you need to add a pref check in here.

Something like:

if self.is_highlight() && !pref!("...") {
    return false;
}

Seems to be fixed after correctly querying the pref.

I can't follow...

Fixed by correctly querying the pref in the CSS code. Changes are reverted.

Priorities and types are not supported yet in this patch. But yes, when one of these properties are changed during runtime, this needs to be propagated (which in worst case could mean remove the selection and add it again).

The default style of a highlight is "do nothing" (not sure if that answers the question or if my code is correct in that case)

Doesn't

if (mHighlightRegistry) {
  mHighlightRegistry->AddHighlightSelectionsToFrameSelection(aRv);
}

work?

It looks like there is a room to optimize how we handle the changes of highlight range, right now we always create a new selection and throw the old one away.
But it seems to me that we could just update the existing selection's range if any. I am okay to live with this for now, but please file a follow up bug for it. :)

nit: bail out earlier for readability.

if (foundIter == mHighlightsOrdered.cend()) {
  return;
}

RefPtr<Highlight> highlight = foundIter->second();

Does annotating Document::CreatePresShell() with MOZ_CAN_RUN_SCRIPT work? Then we don't need to expose this method.

this is missing to unlink the wrapper.
Add NS_IMPL_CYCLE_COLLECTION_UNLINK_PRESERVED_WRAPPER

Yes, this is intentional. I've not yet completely understood how this would work and this PR is more of a "let's get the stuff I already have finished reviewed and landed so we know it works/doesn't break anything, then let's deal with all the more complicated issues".
This goes along with supporting StaticRanges as well and will be a follow-up bug.

let matching_fn = |pseudo: &PseudoElement| pseudo == &pseudo_element;?

Ah, sure, or *pseudo == pseudo_element for that matter.