Browsing that from Firefox Mobile and all I get is Chromium’s logo and the blog title on a blank page.

We are definitely going back to IE-like days

This is kind of the opposite I think. Your browser is blocking assets, probably at your request. Mine is too btw.

That's weird I was about to disagree with you but then I refreshed the page and had the same problem. The debug console showed a lot of content security policy violations for inline scripts.

After some more refreshes it came back. The bug seems intermittent and thus not easily reproducible.

Same here, but it worked the second time, with FF mobile.

I bet there's some race condition somewhere that goes away when whatever file is cached and loads quickly.

Works fine for me with FF 67.0.2 on a current Android 9 image. Are you sure it's not something else?

Turns out it was the tracking protection which blocks some google domains.

Disabling tracking protection for this site (there were 9 of them) worked

Unblocking third party javascript worked for me. That's still idiocy if you'd ask me, but doesn't seem to be google-specific idiocy.

You are right. Disabling tracking protection worked

What did you expect to happen with the endless feature chasing?

Not true. Works fine for me.

> The prefers-color-scheme media query allows a website or web app to adopt the preferred display mode of the user.

Will YouTube and Google themselves support this? I still use extensions to make them dark.

Doesn't YouTube already have a dark mode?

https://support.google.com/youtube/answer/7385323

Thanks. I didn't know it does. Perhaps this has been added recently, I have been using dark-mode extensions for about 5 years.

I believe YouTube has had dark mode for almost a year now.

I'm really annoyed with all of Google's Android apps. a few months ago they updated apps like Gmail, maps, YouTube, etc to be blinding white mode

Does this also include the Google anti adblocker tech?

Does it ultimately matter if this version is the one or not? You have to get off the Chrome pony at some point, why not today!

I've been a Chrome user since 2011. I recently switched to Firefox and I got comfortable instantly. It was the case back in the day that Chrome was super blazing fast. No more. Firefox is amazing, fast and there are few things that still annoy me but they'r minor compared to the philosophical issues I have with using Chrome. Fuck AdTech and fuck Google.

I've also completely switched from GMail after 15 years. I remember signing up for GMail when it was in beta. Now I have a free iCloud email and it works just fine. Plus, Apple is about the only company that I can even begin to trust.

I tried Firefox again, immediately encountered several crashes on youtube streaming and a few other places. Chrome it is for me.

I switched to Firefox around the Quantum release on both mobile and desktop and haven't had a crash since. Did you report your crash to Firefox?

It sends crash reports automatically.

Pragmatically, it does. I don't want to be forced to "get off the Chrome pony" right now as Chrome still is notably faster than Firefox on my computers (which are 5 and 8 years old but still do the job). If the next version of Chrome is the one that is going to break compatibility with extensions I use I'm just going to disable updates and this will give me at least a year - many people use even more outdated browsers are okay.

There are going to be multiple good options based on Chromium that will not break extension compatibility. Brave Browser being the most well-known and polished, but there will be more.

As of this month a Google post claims that the anti-adblocker stuff is still under development. I can't find any sources claiming it is in 76, so I don't think it is.

The change is going to be part of Manifest V3. As of yesterday it is still "very much in development" https://groups.google.com/a/chromium.org/forum/#!searchin/ch... Also they're planning a transition period after which Manifest V2 extensions will be removed from the store, so you'll definitely notice when that happens.

And also it isn't anti-adblocker tech. It is pro-privacy tech which will require adblockers to reengineer how they work which has caused their authors to throw a whine fest and feed some good click bait quotes to the press.

As a veteran chrome extension developer, I'm more inclined to trust extension authors than I am to trust the chrome extension API development team, because it's a bad API with bad documentation and bad performance.

Google's claims that the new API will be faster were already shown to be a blatant lie.

Your argument is that I shouldn't trust my privacy to Raymond Hill but I should trust it to Google?

Accusing someone of astroturfing is specifically against the site guidelines (for good reason, it’s like being accused of being a witch. There is no defense against it).

Maybe edit out that paragraph?

Isn't that only in chrome, not chromium? I didn't think that was being upstreamed.

Opera, Vivaldi, Brave all said they'd change the code to keep the ad blocking capability of uBlock etc. and they build on Chromium.

No.

Can someone explain the appeal of desktop PWA to me? From the developers and the users point of view?

You deploy application once on the web and it can be installed on desktop or mobile device as native app, if user chooses to do so. Or used as webapp in browser. When installed your app has homescreen/desktop icon, opens in separate window. And the best thing - you don't need to pack a whole internet browser with your app (Electron) and worry about pushing updates to user - you just update your app on web. Imagine, that instead of downloading desktop client for Slack, you go to slack.com and click "Install" button. Current negatives are that PWAs still missing support for advanced features like file system access, but browser developers are already working on it. I hope in few years installing VSCode will be as simple as going to their website and clicking "Install".

Desktop PWAs are just like regular desktop applications, except that they work in a web browser as well. This is good because you don’t have to blindly install an app hoping that it will work well and solve your problem, but instead you can just use the app in your browser, and if you like it, you can install it.

It's the only way to make a really cross-platform GUI app. Code once, run everywhere. Many devs/designers also like web tech for letting them make it look and feel almost any way they can imagine.

Run terribly everywhere, with lowest-common-denominator functionality.

I loathe this trend. With everything calling back to a backend in the sky anyway, it should be easier to make light, efficient native shells with good UIs.

Perhaps this is a matter of personal taste but I don't want cloud-backed apps, I won't use anything but 100%-local as long as I have choice.

I also don't want to invest time in developing anything that won't run on all the three major OSes (Mac, Linux and Windows) when built, nor to invest any serious additional effort to achieve this. Being able to run the app in a browser after minimal modification is a nice-to-have bonus (probably very important for many people who develop web-first).

As for now I use WinForms and Qt frameworks to achieve this but I probably am going to switch to Electron if Flutter Desktop doesn't get released soon.

Nevertheless, as a user I would indeed prefer native GUI desktop app talking to their web server for data over a web site.

Perhaps people would develop apps this way if there was a native GUI framework as powerful and easy as web frontend frameworks are and if there was a way to publish you apps a way people could discover and run them in a couple of clicks. Perhaps MS UWP with WPF and Windows Store could do the job much better than web apps but sadly it's not cross-platform.

They demonstrate dark mode with:

color: white; background-color: black;

That's the worst thing possible! Don't do that!

Research how to design for dark mode first. I can't believe they'd put that in their demo snippet of a new feature...

Might as well put _CLICK HERE_ all over the page.

FYI: Does not include Manifest V3 yet, as it is still under-development.

Is this release the one removing the API ad blockers rely on?

no

Don't forget the main feature, it won't let you block those pesky ads!

Maybe I should have added the /s at the end of my comment.

I am aware that the change to the webRequest API has not been implemented yet.

However, I just could not resist having a bit of fun when I saw this headline.

And yes, I actually did switch to FF in light of this announcement from Google.

I actually tried to switch a few times in the past but never really had the motivation to do so. Google gave me the motivation, so I guess, thanks Google!

AFAIK the new proposal allows dynamic filtering, which addresses the primary concern with adblocking tools like uBlock, I believe.

> The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.

https://blog.chromium.org/2019/06/web-request-and-declarativ...

My opinion though is that if you were going to switch over this, just switch anyway.

There is a limit of 30k rules though, which isn't enough to contain even uBO's defaults. While it looks like they are moving to a 150k global limit, even that is less than my current uBO setup of over 200k.

But the article addresses this by saying that the vast majority of rules never get used?

They can work around that by concatenating multiple checks into a single rule though, right?

No, as far as I can tell Gorhill's position on the policy hasn't changed since dynamic filtering was introduced. The primary concern isn't that rules can't be modified, it's that they're declarative -- meaning developers can only use filtering schemes that Google explicitly supports.

It's inaccurate to say that the revised v3 addresses all API concerns.

Oh, ok. I really wasn't sure.

It is not implemented, and ad blocking still works. Also they recently announced more changes to the proposal. To be fair they have some good reasons to change existing api. World is not ending yet.

Their new proposal for blocking ads is exactly the same as the idea Apple offers with Safari, and it blocks ads just fine.

UBlock Origin, UMatrix, Privacy Badger, Decentraleyes, and HTTPS Everywhere are all not available on Safari, in part because the APIs they rely on aren't available.

I'm not sure why people make the claim that Safari is just as good at blocking ads as Firefox and Chrome. It's not. The extension options on Safari are comparatively quite limited, in no small part because of technical decisions like this.

I use UBlock on Safari. It’s there.

I'm on a Mac and just checked the Safari extension store. The only extension I see for Ublock is a fork of Ublock Origin called Ublock Safari. It hasn't been updated in a year, and is thousands of commits behind the official version.

It also isn't distributed by Gorhill, even though the extension lists him as the author in the extension store. In fact, none of this information is listed on the extension page itself.

I'm not sure the extension you're using is what you think it is -- I would be at least mildly cautious about installing it.

See also this issue (https://github.com/el1t/uBlock-Safari/issues/145) on Ublock Safari's Github filled with people complaining that the extension doesn't work and that Safari's tech restrictions mean that there aren't suitable alternatives.

There was a very big thread about this, it's nothing like Apple. The limits are much smaller on the amount of things you can put in a blocklist.

Even if they end up implementing Apple-style simple blocking, they said at the beginning that they would adjust the limits. Most recently, they said the limit would be 150k, which is three times the number Apple allows. https://blog.chromium.org/2019/06/web-request-and-declarativ...

So it's actually a lot like Apple, just with different limits?

Emphasis on idea; IIRC, previous threads have pointed out that Apple hasn't put a limit on their API, or has made the limit much larger.

I'm interested to see how this will affect other browsers built off the Chromium source code, e.g. new Edge, Brave, Opera, etc

Brave and Opera have said they're going to fork and add back the API to allow true adblocking.

Vivaldi has mentioned this possibility as well.

https://vivaldi.com/blog/chromium-ad-blockers-choice/