We've received a few reports (https://github.com/webcompat/web-bugs/issues/108222, https://github.com/webcompat/web-bugs/issues/108297) where some parts of content are missing on bet365.com.

To reproduce:
Visit https://www.bet365.com in Nightly 105.0a1 (2022-08-10) on any platform and observe the page.

Actual:
"Offers" (on the left part) and "Live In Game" sections are missing

Expected:
"Offers" and "Live In Game" sections are displayed

The problem can also be observed on https://www.bet365.com/#/IP/ (a dedicated page for "Live In Game") where the page is not loading.

I run mozregression on my Linux and Windows machines and it's pointing to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=18d92d17a23b606c97efc35b98fe04668bb4e750&tochange=546f112a45914600b9bd09b801bcfff2a9869e2d

Hello André, could take a look at this, please?

[Tracking Requested - why for this release]: The issue is affecting an important site

Set release status flags based on info from the regressing bug 1775254

This is some finger-printing nonsense going wrong on bet365's site. The site computes Math.pow(Math.PI, -100) and requires that the result is exactly 0x359cd9065a12ae6c (1.9275814160560185e-50). Any other result, for example 0x359cd9065a12ae74 (1.9275814160560204e-50) [std::pow from glibc and fdlibm::pow] or 0x359cd9065a12ae75 (1.9275814160560206e-50 [musl::pow] results in the site being non-functional. (V8 is using fdlibm and therefore returning 0x359cd9065a12ae74, so we can likely rule out that the result of Math.pow(Math.PI, -100) is used for anything else than finger-printing.)

The attached patch "fixes" the site, but it's not really the correct solution. Should we move this bug over to "Web compatibility" and try to reach someone from bet365 to correct their browser finger-printing?

(In reply to André Bargull [:anba] from comment #6)

The attached patch "fixes" the site, but it's not really the correct solution. Should we move this bug over to "Web compatibility" and try to reach someone from bet365 to correct their browser finger-printing?

I actually just sent them a message before seeing your comment (to the email address on this page).

(In reply to Jan de Mooij [:jandem] from comment #7)

I actually just sent them a message before seeing your comment (to the email address on this page).

Thanks!

I wonder if this wouldn't be better served by an intervention while the site works on fixing their stuff.

Thanks for looking into this!

I wonder if this wouldn't be better served by an intervention while the site works on fixing their stuff.

I've tried adding the following intervention and indeed it fixes the issue:

const originalMath = Math;
const originalPow = Math.pow;

Object.defineProperty(window.Math.wrappedJSObject, "pow", {
  value: exportFunction(function(base, exponent) {
    console.log('override', base, exponent)
    if (exponent === -100 && base === originalMath.PI){
      return Number('1.9275814160560185e-50')
    }
    return originalPow.call(originalMath, base, exponent);
  }, window),
});

I'll create a patch for the intervention and request an uplift to beta.

As a reminder today is the last beta, if this doesn't make it I can uplift it before we build RC next week.

(In reply to Dianna Smith [:diannaS] from comment #11)

As a reminder today is the last beta, if this doesn't make it I can uplift it before we build RC next week.

Thanks for the heads up, I'm a bit late for that as I wanted to verify the patch in Nightly. I've built a patch for beta and will request an uplift once it's reviewed.

The intervention landed under Bug 1784309.

Is this a wontfix? Seems like something we wouldn't be interested in fixing in a more generic way?

Fair point; it does seem like we'd rather sites get fixed and that we'd rather not do something special for this case.