Open Bug 2020904 Opened 5 months ago Updated 3 months ago

play.lotterywest.wa.gov.au - Firefox is no longer a supported browser

Categories

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

Desktop
Windows 10

Tracking

(Webcompat Priority:P2, Webcompat Score:6, firefox148 affected, firefox149 affected, firefox150 affected)

Webcompat Priority P2
Webcompat Score 6
Tracking Status
firefox148 --- affected
firefox149 --- affected
firefox150 --- affected

People

(Reporter: bfarkas, Unassigned)

References

(Depends on 2 open bugs, )

Details

(Keywords: webcompat:needs-contact, webcompat:platform-bug, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

user-impact-score:500
platform:windows,mac,linux,android
impact:blocked
configuration:general
affects:all
branch:release
diagnosis-team:dom

Attachments

(1 file)

Environment:
Operating system: Windows 10
Firefox version: Firefox 148.0 / Firefox Nightly 150a1 (2026-03-03)

Steps to reproduce:

  1. Access: https://play.lotterywest.wa.gov.au/
  2. Observe the page

Our team has been notified of the error. In the meantime, let's take you back to the home page.

Expected Behavior:
The page is displayed accordingly

Actual Behavior:
A message indicates, that Firefox is no longer a supported browser

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in firefox-nightly, and firefox-release
  • Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/210154

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

User Story: (updated)
Webcompat Priority: --- → P3
Webcompat Score: --- → 1

Even with Chrome Mask, the site errors, but with a different error. It might be the "NS_ERROR_NOT_INITIALIZED" is related? We should figure out why that is.

Severity: -- → S2
User Story: (updated)
Webcompat Priority: P3 → P1
Webcompat Score: 1 → 9
Priority: -- → P1
Webcompat Score: 9 → 8

https://pg.feroot.com/v1/bundle/51faa1e9-552c-4679-ab65-fe604d2bf7f1

      gn(
        n,
        'Window',
        'setTimeout',
        (
          function (r, t) {
            var e = t.targetName,
            o = t.propName;
            return function (t) {
              if ('function' == typeof t) return 'uninitialized' !== n.document.readyState ? r.apply(n, arguments) : r.apply(this, arguments);
              if (zn.disabled) return r.apply(n, arguments);
              if (Wn(e, o), !Sr()) throw new Error('PAGEGUARD: Eval is not allowed');
              return r.apply(n, arguments)
            }
          }
        )
      ),

This sets a proxy on window.setTimeout, but for some reason n is an uninited (or destroyed?) window. n.location.href is "", and n.document.documentElement.outerHTML is just an empty <html><head></head><body></body></html>. Calling setTimeout in this window throws NS_ERROR_NOT_INITIALIZED. Some iframe? But not sure how this happens.

n.document.URL is about:blank, but how is location.href empty in that case? Hmm. And n.document.readyState is complete.

It doesn't look like a webcompat intervention is plausible here, unfortunately. I've tried spoofing Chrome as thoroughly as I can (even adding basic client hint headers), but it seems like they might be hooking into the NS_ERROR_NOT_INITIALIZED error (which I don't think I can work around in an intervention).

User Story: (updated)
Webcompat Priority: P1 → P2
Webcompat Score: 8 → 6
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: