Why Bother with uBlock Being Blocked in Chrome? Time to Switch to Firefox

Re:Why Bother with uBlock Being Blocked in Chrome? Time to S... by londons_explore on Monday November 27, 2023 @04:10AM (#38429994)

> they can't maintain Manifest v2 on their own

The code for manifest v2 is really very simple (when you know that functionality for manifest v3 must remain available) - maintenance of it as an unmerged patch would be pretty straightforward.

I suspect such a patch could be just 10's of lines of code - you're simply changing the condition list under which a web request can be blocking or not.

[ Parent | on HN ]

Re:Why Bother with uBlock Being Blocked in Chrome? Time to S... by aembleton on Monday November 27, 2023 @05:24AM (#38430612)

Isn't it about keeping the manifest v2 API running?

[ Parent | on HN ]

Re:Why Bother with uBlock Being Blocked in Chrome? Time to S... by londons_explore on Monday November 27, 2023 @07:05AM (#38431315)

It isn't a server API or anything... It's just some code in chrome, and it has to remain because it's still allowed to be used in Manifest v3 but for a narrower scope of usecases.

(Note - I'm specifically talking about the controversial WebRequestBlocking part of the changes - the rest of the manifest v2 to v3 migration is largely just like a python 2>3 migration - there is equivalent functionality for everything).

[ Parent | on HN ]

Re:Why Bother with uBlock Being Blocked in Chrome? Time to S... by rekoil on Monday November 27, 2023 @07:08AM (#38431334)

I thought the accepted solution was to just add Blocking WebRequest to the Manifest v3 implementation, which should be simpler than maintaining the entire v2 specification.

[ Parent | on HN ]