Firefox Community Forum

Hi Moz Support,

I've had this happen several times before, but this time it really annoyed me.

I sent tabs from one Firefox instance to another on another device. I closed these tabs on the source device. These tabs were quite old this time, I'd not opened them in a while - this becomes important later.

On the destination device, let's call it "madbilly's destination Firefox", these tabs didn't arrive. After doing a couple of tests where I sent a tab from my mobile to this instance, I realised that this was a similar problem to what I'd had before, which is one where a Firefox instance/profile for some reasons "resets" itself and it seems to create a new instance in Firefox Sync. Tabs which have previously been sent to "madbilly's destination Firefox" don't arrive, because (I think) it's not registered in Firefox Sync as the same instance. These sent tabs, if closed on the source instance (which I did) are lost, unless one reopens the source instance and Ctrl-Shift+T reopens closed tabs. Unfortunately, in this case because the tabs were old and I hadn't opened them for a while there was no way to do this, because Firefox doesn't remember closed tabs which are not stored in memory (another bug, any fix?), except for looking in old session store backups which I'm going to do after I write this post, though I don't know if that will work.

Also, on Android, because it only remembers 10 closed tabs it's not really feasible to retrieve lost sent tabs this way either, and as there's no access to the session store backups the tabs are definitely lost.

Oddly, when this happens "madbilly's destination Firefox" usually appears twice in the send-tab-to menu, but in this case it didn't. To be able to send to this instance I had to sign out of Firefox sync on this instance and sign in again. Then the same instance appeared twice in the sync menu, the old one being now unreachable.

I'd like to know: 1. Why does this happen? 2. How to avoid it happening? 3. Is there a bug registered about this? 4. When will it be fixed and prevented from happening again.

I generally find that this happens when a Firefox instance isn't shut down properly, which on my old desktop I put down to it running out of resources, but on this shiny new laptop from work that doesn't make sense.

All help much appreciated thanks :)

Hello,

I updated my version to 153.0. The Bookmarks left panel was there. I did a CTRL+B, this one disapeared normal But once done I wanted to have my Boorkmarl left pannel back. So I did CTRL+B no Bookmark left pannel was displayed :-(

Regards.

Watching any Bilibili live stream causes severe performance issues. The main problems I can observe are intermittent severe mouse cursor stuttering/frame drops or the cursor becoming unresponsive, accompanied by the taskbar process (explorer.exe) intermittently restarting.

I have tried disabling the Picture-in-Picture feature and tampermonkey add-on, modifying the Windows 11 registry to turn off MPO (Multiplane Overlay), adjusting browser hardware acceleration, and tweaking related settings in about:config, but none of these have been able to prevent the issue.

I came to know about Firefox Widgets but can't see any on Firefox 152 on Windows 11 desktop. The option Allow Firefox to improve features, performance and stability between updates is already checked (Screenshot attached) as suggested by users.

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.

eg https://transportnsw.info/opal-view/#/account/cards is meant to show down arrow next to name - does not appear; go to Profile, Edit address - 'Save as delivery address' checkbox and Submit button do not work. Also had this on the StGeorge bank page https://www.ui.stgeorge.com.au/resolve/etb0/createCustComplaint - Next button does not work. other sites as well have buttons not working (about 20% of sites?) (Sorry both the above examples need accounts to test). Often (not always) if I open the page with Chrome it works. I think they were working ok after macOS update but after a Firefox update went to a very light screen - problem started then.

Also - using about:support the copy raw data button works; the copy text button does not.

Thanks

The "Developer Information" link in the "Developer" section of the release notes page - https://www.firefox.com/en-US/firefox/153.0/releasenotes/ - for Firefox is broken as of v153.0.

1. It attempts to open: https://developer.mozilla.org/docs/Mozilla/Firefox/Releases/153
2. MDN shows a 404 message, and offers a "153" suggested search link which eventually gets me to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/153

I have not tested this for other regions, but without the "en-US" (and possibly other "language-CountryCode" flavors), the link in the Firefox release notes page will not open the Developer release notes in MDN.

Could be an MDN configuration issue if it's not a problem with how links are generated for the Firefox release notes page.

Let me know if I can provide any additional information. Thank you in advance if this issue is fixed.

For the past month this browser has been really slow. I have cleared cache, deleted all history and its really slow. I'm using starlink for internet. any suggestions

Hello, I use KeePassXC as a password manager, and it has a companion Firefox extension called "keepassxc_browser".

Since it's a password manager, I need it to work on all webpages, even restricted ones like the Mozilla account webpage. That's why I've allowed the extension to run on sites with restrictions, as described here. But: Even after enabling that setting for the extension, keepassxc_browser still won't work on accounts.firefox.com. Only after setting `extensions.quarantinedDomains.enabled` to `false` in `about:config`, keepassxc_browser started working on the Mozilla account webpage. But of course doing this opens restricted websites to ALL extensions, which is quite a security hole. So, why "run on sites with restrictions" does not work?

Hi, I am Soumitra Dutta, an Oxford based entrepreneur and photographer. My Firefox browser suddenly stopped working, and I’m not sure what caused the issue. I’ve tried reopening it, but the problem is still there.

Has anyone experienced a similar problem before?

Regards Soumitra Dutta