Firefox experiences Network Protocol Violation on Discourse based Websites

So I have my own Discourse based Forums, and I got a weird Issue that I was conveniently able to reproduce while making an Account over here too. To me personally it happened on Kubuntu LTS 18.04 with the latest Release of Firefox being installed (probably happened the Versions before that too, I only recently switched to Linux and Firefox), and someone else also complained it happened to him on Mint. It also happens to some Users on Windows 10 according to @OvermindDL1 who would be better qualified at explaining all this, and now he gets pinged for not wanting to tell it himself. :stuck_out_tongue:

The Issue itself is that Firefox throws Errors either while logging in using oauth or when already being logged in with a session. It doesn’t happen when you are not logged in or attempt to log in, in some way shape or form.

I took Screenshots of it, while it happened during the Registration of this very Account I am writing this on.

It happens every single time I open a fresh Tab of any Discourse based Site in Firefox that I am logged into, then I need to F5 or hit “try again” and it works again just fine (well until I close the tab and need to open it later again ofcourse).

I could middleclick the bookmark to open the Forums on new tabs and all the tabs created through this will consistently throw that Error and prompt me to try again.

Funnily enough this even happens when the Internet is fully disconnected. Instead of “Failed to Reach Website” I get “Network Protocol Violation”, meaning the Cache is involved in this aswell.

Needless to say this is a very infuriating Issue.


Because I am new and it wont let me post the second Screenshot otherwise. And no I am too lazy to edit 2 Screenshots together into 1. :stuck_out_tongue_winking_eye:

What I know about it is that when those errors appear then there is no request sent to the server, it seems constrained to the service worker itself without ever sending a request. It happens on all discourse sites. It doesn’t happen to my firefox at home on linux (that I’ve seen, but I don’t use it terribly often there), but it happens in firefox at work on win10, and it happens to basically everyone I ask fairly randomly.

1 Like

Does not happen to me at all and I have been using Firefox on windows exclusively for the last week

Something about you config at work is off


It happens to me on my personal Machine too, and it happened ever since I moved from Windows+Chrome to Kubuntu+Firefox last month, and that install of Kubuntu was fresh.

Some Machines have the Issue, some don’t. All I know what I posted here. :wink:

Maybe its even just some security Setting in Firefox causing it.

And I tried without any Firefox Plugins/Extensions, and it still happens.

With all the unreliable Google Search that I have put into this, it is likely that there was some redirect stored in the cache and Firefox for security reasons while loading the site from cache said nope someone wants to hack this. But take this with a grain of salt, because its highly speculative.

I don’t doubt this is happening, but I do not think this is a bug with Discourse.

Mozilla run a public Discourse @LeoMcA has anyone reported something like this to the Firefox bug tracker?

1 Like

I got a screenshot of the Firefox console with the actual error.

One thing that does confuse me here @tgxworld is that I thought we stopped with service workers on desktop no?

Oh, this is the Firefox bug where it doesn’t properly forward the exact network error all the way through to the interface.

@sam a worker is needed for background notifications, though you can not-register a request handler.


That was pushed to the desktop push plugin, should not be required for core

I do have the Notifications enabled, just FYI. Unsure how useful that info is.

I also run on 4G LTE based Internet, certain Websites such as Twitter erroneously want to push their “mobile” version of the website to me because of that, but I think they fixed that, well slightly offtopic.

Edit: and yes it was difficult to even find that Error, as it displays the content of the Error Page itself instead of the Error.

We only disable service workers for apple devices.

@riking Do you know if this is a service worker related bug? From my brief search, it doesn’t seem related to service workers.

I’ve had this multiple times in the following Cases:

A Discourse tab was left in the background and resumed with either no network or a different network (4G to Wifi or vice versa) on Laptop only.

I’ve seen this on my crappy asus netbook which randomly disconnects wifi.

Repro is easy if one has an external wifi adapter or something:
Open Discourse in firefox.
Put laptop to sleep (not sure if it matters but it happens to me only when waking up to a different network)
Remove the wireless adapter (let it use internal adapter if your laptop has one or an inbuilt LTE or wired connection)
Now Just wake up the laptop and it will present a crashed discourse with “Corrupted content error”


Not with Discourse in particular, but with ServiceWorkers in general. This looks to be the expected behaviour when a ServiceWorker errors out in Firefox, but it seems like Chrome lets them fail a little more gracefully:

I can inconsistently repro this (with a fresh profile, on latest release Firefox) on my laptop by toggling my inbuilt wifi adapter on and off. I get the same error as here:

I’m no ServiceWorker expert, but I’m willing to bet the spare change in my coat pocket that this is being caused by this section of code:

I imagine in this weird network-changing state, navigator.onLine is returning true (despite it actually being false), and so an error is being thrown (rather than the offline page being shown) causing Firefox to display the corrupted content error.

Could we check if this error is a network error, and show the offline page in that case too? (Or even wait a little bit, and refresh the page for a user?)


@tgxworld / @falco / @featheredtoast if we nuke the whole concept of proxying by implementing fetch in the service worker, will Android PWA continue to work?

If yes I want this code junked. If no I want the proxy of fetch to be conditional to Android.


I believe that the plugin Privacy Badger causes this to happen a lot with all Discourse sites, for me and one other Firefox user who is test-driving Discourse with me. CTRL + F5 fixes the issue temporarily. Whitelisting Discourse sites greatly reduces the occurrence of these errors.

I reported this to Privacy Badger/EFF about 6 weeks ago. Maybe they fixed it since then, but because I whitelisted the Discourse sites I use, I’ve hardly seen the error and might notice if they implemented a fix.


I’m pretty sure we can have a blank fetch handler and have PWA still work, as long as there is one defined. I’d really like to get offline support going in the future of Discourse, but these issues are definitely frustrating. Wondering if @Falco can chip in for a good path to offline support at this point.

I think we did that before, and it caused some confusion when a discourse server went down, and instead of a “not online” page, we wanted to differentiate that it was actually not responding down and here’s the error vs you being offline.


This a know issue with Privacy Badger:

Firefox also had some problems involving service workers and session restore like 1454400 - Session Restore doesn't activate service worker which affected both Discourse and Microsoft Developer portal login.

Looks like there is a new issue with Firefox online detection.

We need to pass the Lighthouse PWA audit, which requires the offline page, which requires the service worker and proxy.

Exactly, we had that and people complained.


Are you running any third party Firefox plugins @GregoriusTech? If so run in safe mode without them to test. Privacy badger has known issues.

As i mentioned above I did try running without any plugins and it still happens reliably.