iorate
[Bug] Doesn't work at all in Startpage and Qwant
Expected Behavior
No further explanation needed.
Actual Behavior
As the titled suggests. The button to block sites does not appear, and sites that are already banned are not blocked.
Steps to Reproduce the Problem
Just enable uBlacklist and search something on Startpage and Qwant. uBlacklist works correctly in Google and DuckDuckGo.
Specifications
- Browser: Zen Browser 1.7.6b
- Other extensions/add-ons: uBlock Origin (the problem persists with uBO removed)
- Search engine: Startpage / Qwant
- Language: All
- Region: CN, US, SG
same issue on firefox 135.0.1
also no block site links in image searches on ANY of the other search sites, and blocked sites will will show up in image searches.
I have the same problem It must be refreshed once to be useful
Chrome dev 136
I have similar issue, doesn't work at all for duckduckgo Brave 1.79.119 for Mac OS and uBlacklist 8.12.0
Using serpinfo blocking on Firefox android. Startpage search results are not blocked but image search results are blocked.
I can confirm that the issue persists. As pointed out by the reporter, even the "block" icon doesn't appear on Startpage.
I took a quick look at the builtin/serpinfo/startpage.yml file:
root: .w-gl > .result
url: .result-link
The CSS selectors are still valid for the current Startpage search result DOM, so the issue is probably something more complex than can be resolved by just editing the yaml file.
Specifications
- uBlacklist version:
9.1.0 - Firefox:
141.0.3 (aarch64) - macOS:
15.6 (24G84)
For qwant (official support removed in v9, so it's intended that it doesn't work out of the box) you can use this serpinfo:
name: Qwant
version: 0.0.1
homepage: https://www.qwant.com
lastModified: 2025-08-16T00:00:00Z
pages:
- name: qwant
matches:
- https://www.qwant.com/*
results:
- root: 'div:has(>[data-testid=webResult])'
url: a
props:
title: a span
Ublacklist 9.1.0, ff nightly 143.0a1
I think the issue with the startpage SERPINFO might come from here:
- root: .w-gl > .result
The .w-gl is extraneous, can you can block stuff just fine with .result.
This custom SERPINFO seems to fix the problem for me on uBlacklist 9.1.0.
name: My SERPINFO
pages:
- name: Startpage
matches:
- https://*.startpage.com/do/*
- https://*.startpage.com/rvd/*
- https://*.startpage.com/sp/*
results:
- root: .result
url: .result-link
props:
title: h2
$category: [const, "web"]
I think the issue with the startpage SERPINFO might come from here:
- root: .w-gl > .result
The
.w-glis extraneous, can you can block stuff just fine with.result.This custom SERPINFO seems to fix the problem for me on uBlacklist 9.1.0.
name: My SERPINFO pages:
- name: Startpage matches:
- https://.startpage.com/do/
- https://.startpage.com/rvd/
- https://.startpage.com/sp/ results:
- root: .result url: .result-link props: title: h2 $category: [const, "web"]
Odd that an extraneous selector prevents the element from being selected. You'd think as long as the selection itself is targeting the proper elements, the extraneous selector shouldn't technically do any harm. Perhaps uoBlacklist's implementation differs.
Anyways, good catch! You should probably submit a pull request to verify and close this ticket!
Startpage
This issue has been resolved in discussion #664. The CSS selector .w-gl > .result is intentionally designed to distinguish between web search results and video search results (and has been updated to :is(.w-gl, .w-bg) > .result).
Qwant
Official support for Qwant was discontinued in v9 (it wasn't working properly even before that). However, I'm pleased to see users like @sethidden creating custom SERPINFO to add support themselves - this is exactly what the SERPINFO system was designed for!
@sethidden For better performance, you might consider using [upward, 1, "[data-testid=webResult]"] for the root selector instead of the current approach.
