2055176 - flightradar24.com is broken in Private Browsing Mode on Linux

Status: RESOLVED FIXED

(Web Compatibility :: Privacy: Site Reports, defect, P1)

Description

[Jan Jaeschke [:jjaschke]]

When I open www.flightradar24.com in Private Mode on my Ubuntu machine the plane overlay is not showing up. mozregression points to bug 2050515 (which according to the commit message sounds sensible).

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Tom Ritter [:tjr]]

So the site uses luma.gl which does have slightly different branches for different GPU families, meaning depending on your GPU you would be getting different 'workarounds' than normal. The behavior doesn't reproduce for me, so I would be curious to know what your normal GPU strings are, you can get them from https://ritter.vg/misc/ff/webgl.html with ETP disabled.

We can disable the protection on this site, but because the behavior is caused by a library, we may want to investigate a deeper fix...

Comment 3

[Jan Jaeschke [:jjaschke]]

I'm using a NVIDIA GeForce 4080 Super.

---

WebGL Graphics Information

Context: WebGL2 — comparing the default GPU-backed context against one created with willReadFrequently: true.
Property Hardware (default) Software (willReadFrequently)
Context WebGL2 WebGL2
Vendor Mozilla Mozilla
Renderer NVIDIA GeForce GTX 980, or similar NVIDIA GeForce GTX 980, or similar
Unmasked Vendor NVIDIA Corporation NVIDIA Corporation
Unmasked Renderer NVIDIA GeForce GTX 980, or similar NVIDIA GeForce GTX 980, or similar
We pass willReadFrequently: true, powerPreference: "low-power", and failIfMajorPerformanceCaveat: false, but the browser is free to ignore them, so this may not show a difference at all.

Comment 4

[Tom Ritter [:tjr]]

Assuming https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=70127 builds successfully, could you test it and see if it works for you with ETP enabled/disabled?

Comment 5

[Jan Jaeschke [:jjaschke]]

No, with ETP enabled (and Private Browsing Mode) it still doesn't work.

Comment 6

[BugBot [:suhaib / :marco]]

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

Comment 7

[James Graham [:jgraham]]

Do we have any evidence that this affects platforms other than Linux?

Comment 8

[Tom Ritter [:tjr]]

Heh, this also is affecting Brave: https://github.com/brave/brave-browser/issues/53973

Comment 9

[Manuel Bucher [:manuel]]

Updated the user story to make this platform specific. It is also hardware specific. We should still fix by shipping an exception or by determining what is different on the hardware. Will take a look on how to ship an exception.

I'm unable to reproduce on (also on Linux). (On both amd and nvidia graphic cards (5090).

@Jan: Just to be sure that we still need it. Does this bug still reproduce for you?

Comment 10

[Manuel Bucher [:manuel]]

affects:all -> affects:some, because only specific hardware is affected

Comment 11

[Jan Jaeschke [:jjaschke]]

Yeah, still repros on my linux machine.

Comment 12

[Tom Ritter [:tjr]]

So the reason my earlier patch doesn't work is because flightradar bundles luma.gl - so it can't recognize the script to exempt it. It also minifies it, so we couldn't even do a function recognition.

Right now I'm wondering if we can do something where we recognize the user's hardware and if it's a graphics card that would get the LUMA_FP64_CODE_ELIMINATION_WORKAROUND behavior, maybe we return a slightly less sanitized version of renderer...

Comment 13

[Tom Ritter [:tjr]]

Could you set privacy.fingerprintingProtection=true and privacy.fingerprintingProtection.overrides to the following values and let me know if it works or doesn't work?

• "" (aka nothing - this is just confirming it's still broken under normal conditions)
• +WebGLVendorSanitize,-WebGLVendorConstant,-WebGLVendorRandomize,-WebGLRendererConstant,-WebGLRenderInfo
• -WebGLVendorSanitize,+WebGLVendorConstant,-WebGLVendorRandomize,+WebGLRendererConstant,-WebGLRenderInfo
• -WebGLVendorSanitize,-WebGLVendorConstant,+WebGLVendorRandomize,+WebGLRendererConstant,-WebGLRenderInfo
• -WebGLVendorSanitize,-WebGLVendorConstant,+WebGLVendorRandomize,-WebGLRendererConstant,-WebGLRenderInfo

I'm narrowing in on an approach - I think we might be able to keep the unmasked renderer private but reveal a sanitized Vendor. The coarsest buckets would be AMD, Intel, Apple, NVidia, Other...

However this doesn't really explain why this is happening when the individual behaviors luma is doing (LUMA_FP64_CODE_ELIMINATION_WORKAROUND, LUMA_FP32_TAN_PRECISION_WORKAROUND, and LUMA_FP64_HIGH_BITS_OVERFLOW_WORKAROUND) are supposed to be equivalent but less efficient code paths. Maybe their code is broken and we could get it fixed. To help diagnose that, could you also test the following:

privacy.fingerprintingProtection=false and webgl.sanitize-unmasked-renderer=false and then each of:

• webgl.override-unmasked-vendor=NVIDIA Corporation and webgl.override-unmasked-renderer=nvidia
• webgl.override-unmasked-vendor=AMD and webgl.override-unmasked-renderer=amd
• webgl.override-unmasked-vendor=Intel(R) HD Graphics and webgl.override-unmasked-renderer=intel
• webgl.override-unmasked-vendor=Apple GPU and webgl.override-unmasked-renderer=apple
• webgl.override-unmasked-vendor=Mozilla and webgl.override-unmasked-renderer=unknown

Sorry for the battery of tests...

Comment 14

[Jan Jaeschke [:jjaschke]]

privacy.fingerprintingProtection=true, privacy.fingerprintingProtection.overrides:

• empty string: not working
• +WebGLVendorSanitize,-WebGLVendorConstant,-WebGLVendorRandomize,-WebGLRendererConstant,-WebGLRenderInfo: working
• -WebGLVendorSanitize,+WebGLVendorConstant,-WebGLVendorRandomize,+WebGLRendererConstant,-WebGLRenderInfo: not working
• -WebGLVendorSanitize,-WebGLVendorConstant,+WebGLVendorRandomize,+WebGLRendererConstant,-WebGLRenderInfo: not working
• -WebGLVendorSanitize,-WebGLVendorConstant,+WebGLVendorRandomize,-WebGLRendererConstant,-WebGLRenderInfo: working

privacy.fingerprintingProtection=false + webgl.sanitize-unmasked-renderer=false:

• webgl.override-unmasked-vendor=NVIDIA Corporation and webgl.override-unmasked-renderer=nvidia: not working
• webgl.override-unmasked-vendor=AMD and webgl.override-unmasked-renderer=amd: not working
• webgl.override-unmasked-vendor=Intel(R) HD Graphics and webgl.override-unmasked-renderer=intel: not working
• webgl.override-unmasked-vendor=Apple GPU and webgl.override-unmasked-renderer=apple: not working
• webgl.override-unmasked-vendor=Mozilla and webgl.override-unmasked-renderer=unknown: not working

Comment 15

[Tom Ritter [:tjr]]

Oh... That is unexpected.

Specifically, I expected that webgl.override-unmasked-vendor=NVIDIA Corporation + webgl.override-unmasked-renderer=nvidia should have worked.

Wait, I might know the problem, were you potentially testing in PBM? If so, that would explain it - can I ask for another round of tests? These should work in either PBM or Normal

• privacy.fingerprintingProtection=true, privacy.fingerprintingProtection.overrides=+WebGLVendorSanitize,-WebGLVendorConstant,-WebGLVendorRandomize,+WebGLRendererConstant,-WebGLRenderInfo

And then the same battery (I'll make it shorter actually, some should be equivalent) with privacy.fingerprintingProtection.pbmode=false, privacy.fingerprintingProtection=false, webgl.sanitize-unmasked-renderer=false:

• webgl.override-unmasked-vendor=NVIDIA Corporation and webgl.override-unmasked-renderer=nvidia
• webgl.override-unmasked-vendor=AMD and webgl.override-unmasked-renderer=amd
• webgl.override-unmasked-vendor=Intel(R) HD Graphics and webgl.override-unmasked-renderer=intel

Comment 16

[Jan Jaeschke [:jjaschke]]

Yes, this is all in private browsing mode.

(In reply to Tom Ritter [:tjr] from comment #15)

Oh... That is unexpected.

Specifically, I expected that webgl.override-unmasked-vendor=NVIDIA Corporation + webgl.override-unmasked-renderer=nvidia should have worked.

Wait, I might know the problem, were you potentially testing in PBM? If so, that would explain it - can I ask for another round of tests? These should work in either PBM or Normal

• privacy.fingerprintingProtection=true, privacy.fingerprintingProtection.overrides=+WebGLVendorSanitize,-WebGLVendorConstant,-WebGLVendorRandomize,+WebGLRendererConstant,-WebGLRenderInfo

This works in PBM and non-PBM.

And then the same battery (I'll make it shorter actually, some should be equivalent) with privacy.fingerprintingProtection.pbmode=false, privacy.fingerprintingProtection=false, webgl.sanitize-unmasked-renderer=false:

• webgl.override-unmasked-vendor=NVIDIA Corporation and webgl.override-unmasked-renderer=nvidia

Works in PBM and non-PBM.

• webgl.override-unmasked-vendor=AMD and webgl.override-unmasked-renderer=amd

Works in PBM and non-PBM

• webgl.override-unmasked-vendor=Intel(R) HD Graphics and webgl.override-unmasked-renderer=intel

Does not work in PBM or non-PBM.

Comment 17

[Tom Ritter [:tjr]]

Awesome. So this has narrowed it down to two of the luma.gl workarounds - one of them is broken. I'd like to report the bug upstream to them and maybe get it fixed properly. It found one difference between the true and workaround functions, but then convinced itself that that difference couldn't be the cause of this problem. Could you head to https://ritter.vg/misc/stuff/fr24-tan-repro.html and paste the 'Copy full report to clipboard' results (or attach them to the bug). You can do this in any mode (PBM or Normal) - it shouldn't matter. Hopefully with some more empirical data it will be able to figure out where the problem lies.

In any event, our path forward for Firefox is clear: for luma.gl specifically, we can relax the WebGL Vendor protection and that will send luma.gl down the correct paths. We'll do this globally since we can't detect luma.gl specifically. I'll work on those patches.

Comment 18

[Tom Ritter [:tjr]]

Attachment: Bug 2055176 - Bucket the WebGL vendor to a GPU family instead of a constant r?timhuang

Libraries pick driver workarounds off the vendor string, so collapsing it to
"Mozilla" left them on a fallback path that's wrong for the actual hardware.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e29e0a1bf9f4
https://hg.mozilla.org/integration/autoland/rev/cf069dc589db
Bucket the WebGL vendor to a GPU family instead of a constant r=timhuang

Comment 20

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/cf069dc589db

Comment 21

[Jan Jaeschke [:jjaschke]]

(In reply to Tom Ritter [:tjr] from comment #17)

Awesome. So this has narrowed it down to two of the luma.gl workarounds - one of them is broken. I'd like to report the bug upstream to them and maybe get it fixed properly. It found one difference between the true and workaround functions, but then convinced itself that that difference couldn't be the cause of this problem. Could you head to https://ritter.vg/misc/stuff/fr24-tan-repro.html and paste the 'Copy full report to clipboard' results (or attach them to the bug). You can do this in any mode (PBM or Normal) - it shouldn't matter. Hopefully with some more empirical data it will be able to figure out where the problem lies.

UA: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:159.0) Gecko/20100101 Firefox/159.0
flightradar24 tan_fp32 harness - 2026-10-05T09:13:04.799Z

=== Step 0 - environment and which luma.gl branch you are on ===
  parameter               value                   
  VENDOR                  Mozilla                 
  RENDERER                NVIDIA GeForce GTX 980, or similar
  UNMASKED_VENDOR_WEBGL   NVIDIA Corporation      
  UNMASKED_RENDERER_WEBGL NVIDIA GeForce GTX 980, or similar
  VERSION                 WebGL 2.0               
  luma.gl gpu classificationnvidia                  
  => LUMA_FP32_TAN_PRECISION_WORKAROUNDnot defined (hardware tan)
[INFO] Renderer strings are NOT spoofed here. The harness tests BOTH branches anyway, so the results are still valid; but to reproduce the site condition, load this page in a window where privacy.resistFingerprinting (or the WebGL-renderer RFPTarget) is on.

=== Step 1 - does a literal 1.0 / 0.0 compile at all? (Factor A2) ===
  case                    COMPILE_STATUS          info log                
  bare constant           ERROR                   0(6) : error C7532: global function uintBitsToFloat requires "#version 330" or later 0(6) : error C0000: ... o
  luma.gl form (guarded)  ERROR                   0(9) : error C7532: global function uintBitsToFloat requires "#version 330" or later 0(9) : error C0000: ... o
  const initialiser       ERROR                   0(6) : error C7532: global function uintBitsToFloat requires "#version 330" or later 0(6) : error C0000: ... o
  0.0 / 0.0 (NaN)         ERROR                   0(6) : error C7532: global function uintBitsToFloat requires "#version 330" or later 0(6) : error C0000: ... o
[FAIL] *** A constant division by zero is REJECTED by this driver. Factor A2 is CONFIRMED: the vertex shader of every deck.gl layer fails to compile whenever the workaround is defined, which takes the whole overlay down. ***

=== Step 3 - is the 1.0/0.0 guard ever reached? (Factor A1) ===
[DIM] The single call site is project_mercator_, whose argument is PI*0.25 + radians(clamp(lat,-89.9,89.9))*0.5. Static analysis says that is confined to [0.00087, 1.56992] rad and the guard needs >= 3.92699. This measures it on your GPU, in case floor()/int() behave differently here.
[FAIL] cannot run - shader did not build

=== Step 4 - how far apart are the two tan implementations? (Factor B) ===
[FAIL] cannot run - shader did not build

=== Step 5 - does the taylor path ever produce Inf/NaN where hardware tan does not? (Factor A3) ===
[DIM] A3 is the hypothesis that the driver accepts 1.0/0.0 but the constant-folded infinity, or the branchy reconstruction, poisons the function at runtime - wrong values, no error.
[FAIL] cannot run

=== Step 6 - end-to-end: clip coordinates for realistic flight positions ===
[DIM] Reproduces deck.gl WEB_MERCATOR mode (zoom < 12): common position from project_mercator_, then translate by the viewport centre and scale by 2^zoom, as the viewProjectionMatrix does.
[FAIL] cannot run

=== Step 6b - what does Firefox actually hand the GPU driver? (decides A2) ===
[DIM] Firefox translates every WebGL shader through ANGLE before the native driver compiles it. If ANGLE folds the 1.0/0.0 away, the driver never sees a division by zero and A2 cannot happen on any driver, not just this one.
  property                value                   
  translator output language#version 150            
  still contains a division by zerono                      
  folded to an +Inf bit patternYES - uintBitsToFloat(2139095040u)
[PASS] Factor A2 is REFUTED structurally, not just empirically: ANGLE rewrites "return 1.0 / 0.0;" to "return uintBitsToFloat(2139095040u);" (0x7F800000 = +Inf) before the driver ever sees it. The native GLSL compiler is handed a perfectly ordinary bit cast, so it cannot reject a division by zero. This holds for every driver under Firefox.
[DIM] translated excerpt:
8548 * webgl_5e92ca9401546dfa));
  float webgl_138cc122551b2816 = 0.0;
  float webgl_373240156d8fca68 = floor(((webgl_464d3b1340320851 / 1.57079637) + 0.5));
  int webgl_61419000f768455b = int(webgl_373240156d8fca68);
  if (((webgl_61419000f768455b < -2) || (webgl_61419000f768455b > 2)))
  {
    return uintBitsToFloat(2139095040u);
  }
  (webgl_138cc122551b2816 = (webgl_464d3b1340320851 - (1.57079637 * webgl_373240156d8fca68)));
  (webg
[DIM] canvas cvA (hardware): 11357 lit pixels of 1400 points
[FAIL] canvas cvB: shader build FAILED - 0(58) : error C7532: global function uintBitsToFloat requires "#version 330" or later
0(58) : error C0000: ... or #extension GL_ARB_shader_bit_encoding : enable
0(58) : error C0000: ... or #extension 

=== Step 7 - visual comparison ===
  (compare the two canvases in the page; if the right one is empty or scrambled, that is the bug)