Page 1 of 1

Headsup: cef-builds site broken in < Chrome85, Debian on 83

PostPosted: Thu Nov 19, 2020 9:33 am
by i336
Hey, just a quick shoutout that https://cef-builds.spotifycdn.com/index.html does not show any content for me, and looks kind of broken (I just started looking at CEF for a personal project and my initial reaction was "aww, did the binary builds service bitrot? :(").

A quick look in the devtools reveals that a) an "index.json" is being fetched OK and shows promising data; and b) "TypeError: url.replaceAll is not a function". Uh, wha?

After googling replaceAll and perusing String.prototype.replaceAll at https://developer.mozilla.org/en-US/doc ... replaceAll, I was surprised to see that this new function's Chromium support starts at version 85. Wow, that's really recent!

So recent, in fact, that Debian Stable's latest version of Chromium is 83, and FWIW, Ubuntu appears (https://packages.ubuntu.com/search?keyw ... ection=all) to have *just* released 85 at the time of writing this.

I suspect most users visiting the cef-builds page are developers specifically setup with canary/development builds of everything in order to catch issues as early as possible. I guess this is one of the few unhandled failure conditions of this approach, which is entirely understandable. :)

- i336_

Re: Headsup: cef-builds site broken in < Chrome85, Debian on

PostPosted: Thu Nov 19, 2020 10:08 am
by magreenblatt
This is a known issue that we're not intending to fix. Google Chrome, Edge, Safari and Firefox have all supported this method since approximately July 2020. We're talking default installs here, not canary/development builds.

I'm surprised that Debian's version of Chromium is so old. Going 7 months without security fixes doesn't sound like a good idea.

Re: Headsup: cef-builds site broken in Chrome < 85, Debian o

PostPosted: Fri Nov 20, 2020 12:20 am
by i336
TIL. I knew Debian was conservative, but... I'm surely not the first to be really surprised at the ramifications :roll: - and on the web browser front it is indeed not ideal to be running so far behind. A tricky situation indeed.

In any case, keeping the codebase free of backward-compatibility workarounds is completely understandable, especially given userbase expectations (I mean, nobody's reported this until now...). And now there's documentation for the three people stuck on CentOS or whatever ;).

Thanks again.