I-Firefox Community Forum

Amazon Facebook Ebay National Lottery and others just refuse to load.I tried troubleshooting mode,it worked once and now it doesn't.I believe I'm not the only one with this prob. Help? Thanks.

別のノートパソコンやスマフォではアクセスできるがデスクトップパソコンだけで　https://www.minim.jp/　アクセスできない。他の多くのサイトにはアクセスできる。

今まで利用していたChromeでもEdgeでも10日前にアクセスできなくなったので、試しにFirefoxをインストール、その後、このサイトにアクセスできた。それでhttps://www.minim.jp/に接続するときだけ、Firefoxを利用していた。

しかし、28日アクセスすると「エラーコード: PR_END_OF_FILE_ERROR」が出るようになりアクセスできなくなった。 現在もChromeやEdgeではアクセスできない。

問題箇所が不明で改善方法が分かりません。 問題箇所、改善方法をご教示ください。

Windows11　Firefox　146　です。 ウイルスバスターの問題かもしれないと思ってアンインストールして、確かめたが改善されなかった。 ChromeやEdgeの公式版のβ版(最新バージョン)でも改善しませんでした。 OS　25H2　26200.7462で最新版

I access Bluesky (bsky.app) for business on my PC. Since the last update, I've been unable to access Bluesky from my regular Firefox browser. I can using other browsers, the mobile app, and, oddly, in Firefox private browsing. I've cleared my browser history, cookies, etc. I restarted the computer. I logged out of Bluesky (and now can't log back on the regular PC account because it claims I'm not connected to the internet). Yet, I had no trouble logging in using private browsing.

I've looked through settings, etc. and can't figure out what could be limiting my ability to access this website.

Madam or Sir,

I do not know what happens but since a few days I cannot access any more https://mathworld.wolfram.com/ which is crucial for my work.

Since I am blind, could you please help me.

I thank you in advance

Best regards

Claude F. Leibovici

Our team has already tried to fix the issue for a week now and none of the approaches seem to fix the issue. Does the Firefox dev department have any hints or clues for us?

Short description: Firefox network.lna.blocking blocks same-origin/loopback requests when the page is controlled by a Service Worker

Symptom: Login via OIDC fails in Firefox (the backend call after the IdP redirect is blocked). The error disappears if either network.lna.blocking=false is set or the Service Worker is disabled.

Environment: - Frontend (react) and backend run on the same machine (loopback/localhost)—no cross-network scenario. - Firefox with active network.lna.blocking (experimental Local Network Access feature, Chromium’s equivalent is Private Network Access).

Root Cause (Analysis): 1. apps/react/sw.js registers a global fetch listener via Workbox and calls workbox.core.clientsClaim(). This causes every open page to be immediately controlled by the Service Worker. 2. registerServiceWorker() is called unconditionally on every app start, regardless of authentication state—even on the login/OIDC page. 3. The app uses hash-routing (URL fragments like “#/oidc”); the login page and the rest of the app share the same document URL, so you can’t restrict the SW scope to “everything except login.” 4. Once a page is Service-Worker-controlled, every fetch—including requests not explicitly handled by Workbox routes—first goes through the SW’s fetch event (default behavior when any fetch listener is registered) before proceeding to the network if it isn’t intercepted. 5. Hypothesis: Firefox’s LNA implementation doesn’t correctly inherit the address-space classification (loopback/private/public) for SW-forwarded requests across the controlling client. A direct document fetch (loopback→loopback) is allowed, but an identical target fetch routed through the SW is blocked.

Reproduction (minimal): 1. Use Firefox with network.lna.blocking=true (the default in affected versions). 2. Load a page that registers a Service Worker with a fetch-event listener (e.g. via Workbox precacheAndRoute + clientsClaim()). 3. Ensure both the page and the target resource are served from localhost/loopback. 4. From the SW-controlled page, call fetch() against the loopback target resource → the request is blocked. 5. By comparison, the same fetch from a non-SW-controlled page succeeds. 6. Setting network.lna.blocking=false also allows the fetch to succeed under SW control.

Excluded Causes: - Different address spaces for frontend/backend (both are on the same loopback machine)—ruled out. - Misclassification due to redirect_uri or cross-origin navigation—the OIDC redirect is a top-level navigation (unaffected); only the subsequent backend call (token exchange/session validation in SsoLogin.tsx → ssoLoginSubmit) fails.