1678795 - NS_ERROR_DOM_ABORT_ERR while opening web.telegram.org and slack.com (frequently involving hit quota limits)

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, defect, P2)

Description

[Anatoli Babenia]

Attachment: ns_error_dom_abort_err.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

1. Open new tab
2. Enter "web" to get "https://web.telegram.org/" from autocomplete
3. Press enter

Actual results:

Nothing at all.

When I repeat with console and network tab open, I get this NS_ERROR_DOM_ABORT_ERR error as in attached screenshot. Running in safe mode doesn't help.

The website loads in private tab only.

Expected results:

Open a web site or at least show an error.

Comment 1

[Anatoli Babenia]

Attachment: about:support

Comment 2

[Anatoli Babenia]

Attachment: about

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 4

[Anatoli Babenia]

I don't know what happened, but it started to work now. I didn't reload browser, which is still in safe mode since my last post.

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am closing this one, but please feel free to reopen if you are facing the problem again.

Honza

Comment 6

[Ivan Savov]

I'm seeing the same problem NS_ERROR_DOM_ABORT_ERR today when trying to open:
https://app.slack.com/

about:support info posted here https://minireference.com/static/tmp/about_support.txt

Tried restarting; tried clearing cookies.

Comment 7

[Ivan Savov]

Other things I tried in case that might fix:

• Rebooted computer
• changed DNS servers
• restart FF with no addons

But no, still can't load page due to NS_ERROR_DOM_ABORT_ERR.

Let me know if I can help debug this further. Very reproducible.

Comment 8

[Ivan Savov]

Attachment: about_support.txt

This is the about:support output (same as in weblink to minireference)

Comment 9

[Anatoli Babenia]

There should be at least a better way to debug this error, so I reopen it.

@Ivan maybe you are located in Belarus by any chance? Here the government forces certain operators to deploy ill functioning DPI systems for blocking and censoring protests, and I won't be surprised if they try to block Slack too. Intentionally or just because they don't know what they are doing..

Comment 10

[Ivan Savov]

No no. I'm in Canada. We have our share of incompetence here too, but no network blocking yet ;)
Also it was working earlier today.

In retrospect, I've experienced enter-previously-visited-URL-and-nothing-happens error before (page doesn't load; nothing changes). This was happening maybe for past 3 months, very speradially and temporarily (for like 10-20 minutes) when trying to open https://mail.google.com It had never happened on any other sites before, so I thought it was a gmail problem, but because it happened on slack today I looked into it more and found the mysterios ERR msg.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Martin Bonneau]

Hi all, I have the same bug since the 82 update in my WebApplication (Progressive Web App)
I develop my app with the framework Ionic4 with Angular, and it seams that Firefox doesn't catch correctly anymore Promises in some certain cases. For me, it's a specific POST request with a lot of options and a long response from the API
I openned a case here with more details. I paste here main informations about what I tried :

• Using a different navigator (chrome) --> works
• Try to make an other POST request, here for login (works fine) (exclude API or security problem) --> works
• Using a old version of firefox (62) --> works fine
• Then update to actual firefox version (82.0.2) --> doesn't works anymore
• Using "private navigation" --> works
• Delete cached data and cookies --> doesn't change anything

One additionnal thing : when I'm running the app in "dev mode", it works perfectly (the web app is hosted on localhost but the API is still on the remote server). When I put the app on the same server of the API, I get the error.
When I say to the app to use the API hosted in another server, it works perfectly

In conclusion, in my case, the problem in ONE POST request, when the PWA request the API on the SAME serveur. I didn't try to use Observable as Promise. If you want me to try it or anything else, I can

I hope that the source problem is the same and my contribution can help.
Maybe the error is throw by here:22

Comment 13

[Ivan Savov]

@Martin Bonneau : is there a public URL I can visit to try to reproduce?

It definitely seems like a good track to explore...

Comment 14

[Martin Bonneau]

I'm sorry @Ivan Savov but no, it's a private app who allow to deploy virtual machine, you understand that we can't expose it
It's not the best way to do, but say me how I can help as much as I can

It's verry mysterious cause it doesn't appened in private mode, or when the app and the api are not in the same server.... Maybe a problem with the ACCESS_CONTROL_ALLOW_ORIGIN header with apache2 in certains cases ? Or a conflict with the http_client of angular ... I don't know sorry !

Tell me which informations you want me to share

Comment 15

[Martin Bonneau]

In addition I guess that if the request fail (in the api side, causing a very short response time), the error doesn't occur, I have to check this information with a mock response from the api if needed

Comment 16

[Hubert Boma Manilla (:bomsy)]

Hello Anatoli or Martin ,
This is not looking like a devtools issue.
Can you confirm that you seeing the issue with the developer tools closed?
If so i can move this over to the Networking component so it can get addressed.

Thanks

Comment 17

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Removing NI, we need answer for comment #16 first

Comment 18

[Anatoli Babenia]

@bomsy on my side I am pretty sure I saw that without open devtools. I usually open them after problems, not before. What I expected, though, is that devtools contain more informationto troubleshoot the cause of the error.

Comment 19

[Ivan Savov]

I can confirm as well. Error occurs during normal usage, but I used devtools to see the error msg.

Comment 20

[rokasrudys]

Faced the same issue for the last couple of months, not sure since what update.

This happens to me on various other websites for example outlook, using a different browser works so assume its browser request handling.

After playing around with it unregistering service worker in the application inspector and reloading fixed the issue, if it happens again will provide more detail.

Comment 21

[Martin Bonneau]

(In reply to Hubert Boma Manilla (:bomsy) from comment #16)

Hello Anatoli or Martin ,
This is not looking like a devtools issue.
Can you confirm that you seeing the issue with the developer tools closed?
If so i can move this over to the Networking component so it can get addressed.

Thanks

Hi, sorry for late response
I can confirm that the error occur even the Debug tab is closed. There is an error both in network tab and in the console tab. Only the network tab show the "NS_ERROR_DOM_ABORT_ERR", in the console tab I have an error from the service worker. I can paste it here if needed

Maybe there's something to search around service worker and promises handling

I'll try monday to unregister the service worker + reloading the app as say above

Comment 22

[Martin Bonneau]

Attachment: OK

.

Comment 23

[Martin Bonneau]

Attachment: long_stacktrace.txt

I just tried to unregister the service worker and reload the page : it doesn't change anything for me
Same error in "network" tab, and in console tab I have this error :

```javascript
ERROR Error: Uncaught (in promise): S: {"headers":{"normalizedNames":{},"lazyUpdate":null,"headers":{}},"status":0,"statusText":"Unknown Error","url":"https://infrahub.prod.svc.mydomain.ext/api/terraform","ok":false,"name":"HttpErrorResponse","message":"Http failure response for https://infrahub.prod.svc.mysdomain.ext/api/terraform: 0 Unknown Error","error":{"isTrusted":true}}

[long stacktrace]

```

Comment 24

[Martin Bonneau]

Sorry for spaming messages, just ignore the comment #22 or if someone can remove it

Comment 25

[Rasmus Sigsgaard]

Attachment: app.slack.com_Archive.har

Comment 26

[Rasmus Sigsgaard]

Attached app.slack.com_Archive.har with cookies redacted.

Experiencing the same today trying to access a Slack workspace.

Comment 27

[Hubert Boma Manilla (:bomsy)]

Thanks all for the details ...I'll move this to the Network Component.

Comment 28

[pauljb1975]

Just started getting this problem with Slack. Slack was working fine an hour ago, and now I get this error. I didn't do anything to FF (updating, etc.) or any other component of my network -- it just stopped working for no apparent reason.

Comment 29

[Kershaw Chang [:kershaw]]

Could you try to get the http log?
If the http request is really canceled by NS_ERROR_DOM_ABORT_ERR, this could not be a networking bug. But the http log can tell us something.

Comment 30

[Rasmus Sigsgaard]

Attachment: log.txt-main.34792.moz_log

HTTP log going to https://app.slack.com/client/T04A5GN6Q/C04A5GN6Y

Comment 31

[Rasmus Sigsgaard]

Attachment: log.txt-main.34336.moz_log

Smaller HTTP log in safe mode.

Comment 32

[Kershaw Chang [:kershaw]]

(In reply to Rasmus Sigsgaard from comment #31)

Created attachment 9193224 [details]
log.txt-main.34336.moz_log

Smaller HTTP log in safe mode.

Thanks for the log.
This looks like related to service worker.
See the log below. In nsHttpChannel::Connect(), nsHttpChannel::RedirectToInterceptedChannel() is called and a new channel 0000000026A76800 is created.

2020-12-15 12:18:32.560000 UTC - [Parent 34336: Main Thread]: D/nsHttp nsHttpChannel::Connect [this=0000000023DEE000]
2020-12-15 12:18:32.560000 UTC - [Parent 34336: Main Thread]: V/nsHttp Creating HttpBaseChannel @0000000026A76800
2020-12-15 12:18:32.560000 UTC - [Parent 34336: Main Thread]: E/nsHttp HttpBaseChannel::Init [this=0000000026A76800]
2020-12-15 12:18:32.560000 UTC - [Parent 34336: Main Thread]: E/nsHttp host=app.slack.com port=-1
2020-12-15 12:18:32.560000 UTC - [Parent 34336: Main Thread]: E/nsHttp uri=https://app.slack.com/client/T04A5GN6Q/C04A5GN6Y

After awhile, the channel is aborted with error 80530014, whihc is NS_ERROR_DOM_ABORT_ERR.

2020-12-15 12:18:41.518000 UTC - [Parent 34336: Main Thread]: D/nsHttp HttpAsyncAborter::AsyncAbort [this=0000000026A76800 status=80530014]
2020-12-15 12:18:41.519000 UTC - [Parent 34336: Main Thread]: V/nsHttp HttpBaseChannel::DoNotifyListener this=0000000026A76800

Comment 33

[pauljb1975]

Attachment: slack-fail.txt

Attaching my log file.... I want to note that if I clear my cookies, or use private browsing mode, it works again.

Comment 34

[David Lawrence [:dkl]]

The content of attachment 9192998 [details] has been deleted for the following reason:

Deleted at request of author

Comment 35

[Tom Tung [:tt, :ttung]]

Ni Yaron, Andrew per comment 32.

Comment 36

[Ivan Savov]

Quick note: tried accessing Slack today using Firefox updated to 84.0 and error still occurs.

Comment 37

[Andrew Sutherland [:asuth] (he/him)]

This may be bug 1668743. I think the main question is: Were the sites that are failing to load the next time they are opened still in open tabs the last time the browser shut down? This is usually the case for pinned tabs, but can also be the case for other tabs as well, especially for people like me who tend to never manually close tabs.

If not, we may be looking at alternate variations in corruption of profile storage.

(In reply to Anatoli Babenia from comment #9)

There should be at least a better way to debug this error, so I reopen it.

Absolutely agreed. I'll be landing some improvements to about:serviceworkers in bug 1506892 that will make it a lot easier to figure out what's going on in situations like this once the involvement of ServiceWorkers is understood or suspected.

Comment 38

[Rasmus Sigsgaard]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #37)

This may be bug 1668743. I think the main question is: Were the sites that are failing to load the next time they are opened still in open tabs the last time the browser shut down? This is usually the case for pinned tabs, but can also be the case for other tabs as well, especially for people like me who tend to never manually close tabs.

I do not use pinned tabs, and still get NS_ERROR_DOM_ABORT_ERR going to a Slack workspace, even after restarting in safe mode with all tabs closed.

Comment 39

[Rasmus Sigsgaard]

Attachment: image.png

Coming across bug 1622535 I tried clearing Cached Web Content, but it did not help. Then I saw in Manage Data that app.slack.com is taking up 2GB of storage. I would like to avoid clearing all of my cookies, so I hope the solution is not just clearing all cookies and site data. I will leave it for now in case you need more information for debugging.

Comment 40

[Andrew Sutherland [:asuth] (he/him)]

Very interesting! 2 GB is our per-origin storage cap unless the site has requested persistent storage via navigator.storage.persist(), so that is potentially related to the problem. Thank you very much for this information!

It's fine to clear just the app.slack.com storage (which will not affect any other offline storage or cookies). Knowing that we could be experiencing quota issues here is very useful for me to locally replicate and analyze. Also, it's possible that the update situation I talked about above could be responsible for storage "leaking" that could have resulted in some of the storage use. And it sounds like you already know how to clear just that storage, but for anyone else reading this, here are 2 very similar support pages that both tell you how to do that:

• https://support.mozilla.org/en-US/kb/clear-cookies-and-site-data-firefox#w_clear-cookies-for-any-website
• https://support.mozilla.org/en-US/kb/storage

Comment 41

[Rasmus Sigsgaard]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #40)

It's fine to clear just the app.slack.com storage (which will not affect any other offline storage or cookies).

I tried going to storage inspector to see if it showed what was taking up the space, but since the page wouldn't load, it didn't change to show the correct storage.

Clearing storage for app.slack.com fixed the issue, and the Slack workspace loads correctly now.

Comment 42

[Martin Bonneau]

I tried to remove datas too ; but it didn't change anything in my case for the app I developp
It still works in private mode

Comment 43

[batman.nsit]

I was able to repro same error when visiting web.whatsapp.com (in browser companion app for whatsapp)

I could figure it out as a developer, for a layman it would make sense to give proper error message and quick fix button?

Comment 44

[vinc]

Just to add as to the scope of this problem; I am not a heavy user of Slack, and not a very tech user nor a dev.

I found this bug page because I tried googling the NS_ERROR_DOM_ABORT_ERR error I found digging in the dev tools.

Followed the instructions at https://support.mozilla.org/en-US/kb/storage

and yep; app.slack.com Storage 2.0 GB

Clearing it makes the site work again.

Would be good for firefox to not just fix this, but make sure that there is some communication around this kind of thing going wrong.

Because the layman's perspective here is "one site I rely on for work just stopped working in Firefox for no reason and without explanation or way to fix it."

Comment 45

[Julian Descottes [:jdescottes]]

Faced a similar issue when trying to log in to gmail after the holiday break. It worked fine with a new profile but not with my regular nightly profile.
I tried disabling every possible devtools custom setting as I first believed it might come from Netmonitor's network blocking, to no avail.

I finally found this bug and as suggested here, I cleared mail.google.com's storage but it was only taking up 660MB, not 2GB. I also cleared cached web content at the same time. Then tried to login again and it finally worked. Sadly not sure which one of the two actually fixed the problem.

Comment 46

[Anatoli Babenia]

Telegram on mobile can easily cache 2Gb of data. I'd like to see the size of cache for the web version in Firefox. Maybe even on the error page, with a button to clear it.

Comment 47

[Masatoshi Kimura [:emk]]

Regarding the "nothing happens" error, I recalled bug 1050329. I think we should at least show an error page.

Comment 48

[davidshepherd7]

Another data point in case it helps: I had this issue with slack. It was consuming only 232MB of storage, but I tried clearing it anyway and it fixed my problem. Firefox 84.0 on Ubuntu 18.04.

Were the sites that are failing to load the next time they are opened still in open tabs the last time the browser shut down? This is usually the case for pinned tabs, but can also be the case for other tabs as well, especially for people like me who tend to never manually close tabs.

I don't think I had slack open last time I shut down my browser. But also: the problem started without me shutting down the browser. I closed my slack tab, did some other work, and when I tried to open slack again ~15 minutes later I ran into this issue.

In case it's relevant: I don't use any pinned tabs.

Comment 49

[Adam Bittlingmayer]

My Firefox on Mac is suffering from this issue. It affected some websites but not others with no clear rhyme or reason except that it's those I use most. (So, mail.google.com, but not drive.google.com.) I have no add-ons enabled. They do work in a private window.

I am able to resolve it websites by website by going to about:preferences#privacy and then Cookies and Site Data > Manage Data and removing cache and cookies for the specific website. Of course, I would rather not do that for all websites.

Comment 50

[Daniel Morante]

I came across this bug while searching for NS_ERROR_DOM_ABORT_ERR. I am experiencing the described issue when visiting https://forum.virtualmin.com/. I can't describe when this problem started (as of right now this is the first time opening the site since July 2020).

Opening the page in a private window works.

Application Basics
------------------

Name: Firefox
Version: 84.0.1
Build ID: 20201225015510
Distribution ID:
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:84.0) Gecko/20100101 Firefox/84.0
OS: FreeBSD 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC
Multiprocess Windows: 3/3
Fission Windows: 0/3 Disabled by default
Remote Processes: 10
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Missing
Safe Mode: false

Comment 51

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

[Tracking Requested - why for this release]: Pages fail to load. At least 8 people who experienced the issue found this bug which required to check the Netmonitor tab in the developer tools.

Comment 52

[Julien Cristau [:jcristau]]

Andrew can you take another look here?

Do we have telemetry for this error?

Comment 53

[tjkopena]

This problem came up for me today using Slack, it simply refused to load in Firefox Developer Edition for Arch Linux 86.0b3 (64-bit). The service worker's request to app.slack.com reported NS_ERROR_DOM_ABORT_ERR in the network tools (which were not open in the initial attempts). After finding this report I was able to make the site work again by clearing all cookies for slack.com. As with reports above, the cookie manager reported that app.slack.com was taking up 2GB. Since the last time it worked my browser had not been closed, but Slack in a pinned tab had been closed; i.e.:

1. Slack is working in the browser in a pinned tab
2. Pinned tab for Slack is closed but browser is left open (GMail and Google Calendar pinned tabs still open, for what it's worth)
3. Several hours pass
4. A new regular tab is opened but Slack will not open in it

Comment 54

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Julien Cristau [:jcristau] from comment #52)

Andrew can you take another look here?

General context: I'm pursuing a fix for the root cause of lack of opportunity to activate new ServiceWorkers for tabs left open through browser shutdown (inclusive of pinned tabs) but which don't call skipWaiting() in bug 1668743. Garbage-collection/cleanup of orphaned Cache API storage for ServiceWorkers is being handled in bug 1665197.

In the many helpful comments (Thank you commenters!) it seems clear that Slack on Firefox is experiencing additional complications because of its ServiceWorker's large install footprint of ~210 MB of Cache API data. This will likely require additional compensation by cleanup attempts planned as part of bug 1665197. However, there's a potential real ongoing problem where Slack's cache retention logic will cause users to retain 4 usable installations in steady state for disk usage of ~800-900MiB as upgrades occur in a fashion that will lead to breakage if the profile's quota limit per group is less than that.

Reading the current slack SW script's logic, the general approach taken is:

• During the "install" event:
  • Check if there is a SW Cache API storage that's less than a day old. If there is, then its contents can be used.
  • Process the manifest of things to install where all resources include embedded version numbers and 7-digit hex hashes or cache-busters. If there are existing Cache API caches from previous versions of the ServiceWorker cache that are still "valid", then first check those caches and if they contain the desired Response, put it in the new "modern" CACHE_KEY cache being populated (via dipAndCache). If an existing cache entry isn't found, it goes to the network (via fetchAndCache).
    • The validity check logic is: Always keep the 3 most recent Caches (ignoring the new target cache) plus any cache that's less than 4 days old (but inherently >= 1 day old since we would have just reused such a cache).
  • skipWaiting() gets called. This suggests that the slack ServiceWorker should not actually be experiencing the problem of bug 1668743 as long as creation of all of the install steps are successful. But in the event of Quota limits being hit, things will fail and not self correct. The SW script itself does not attempt to detect quota problems and compensate (inclusive of QuotaExceededError and navigator.storage.estimate()) or perform any cleanup as part of the install phase prior to adding new usage.
• During the "activate" event:
  • Purges old caches as reported via getInvalidCacheKeys(). Similar to the validity check, the 3 most recent caches (excepting the current cache) are retained regardless of age, and then any cache older than 4 days is deleted. Given the 1-day recency logic at install time, the expected behavior is just that the 3 most recent caches (per MINIMUM_BUCKETS) will be retained.

Do we have telemetry for this error?

None that I'm aware of or was able to quickly discover (in other areas of the code base related to navigation and navigation loads).

Comment 55

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Yesterday I had to clear the user data for Slack because the site didn't load (last week it loaded after a Nightly restart) and today it's back to not loading (Preferences > Privacy & Security > Manage Data mentions 262MB for app.slack.com).

Comment 57

[Dave Townsend [:mossop]]

Not sure I saw it mentioned here, but I was hitting this with mozilla.slack.com. Looking at storage showed app.slack.com using 2.0GB and mozilla.slack.com using 3.7KB. I deleted the data for mozilla.slack.com and it fixed it, I did not need to delete the data for app.slack.com.

Edit: Ah I guess it only fixed it for a few minutes then it broke again. I did indeed have to delete all the slack data.

This is a really nasty error I hope we can at least show some kind of message to the user when it happens.

Comment 58

[Arne Brasseur]

This started happening for me on Firefox Nightly (Firefox 88.0a1 build 20210303215027) since yesterday, all requests to app.slack.com seem to lead to NS_ERROR_DOM_ABORT_ERR.

Clearing all site data for any domains related to slack did not fix it. It's not a networking problem, it loads fine in a different browser.

about:support : https://gist.github.com/plexus/88f4e25e179eb0b81afaa9e6ff2357ea

Comment 59

[ivano.picco]

Hey, I got his problem today using Gmail in a pinned tab. I read here it could be related to the service workers therefore I made an attempt by deregistering all the workers from about:serviceworkers and reloading the pinned tab. It worked. So, as a temporary workaround, I have just installed this extension: https://addons.mozilla.org/it/firefox/addon/block-service-workers/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search which is blocking the service workers to be registered.

Comment 60

[jonatan]

(In reply to vinc from comment #44)

Just to add as to the scope of this problem; I am not a heavy user of Slack, and not a very tech user nor a dev.

I found this bug page because I tried googling the NS_ERROR_DOM_ABORT_ERR error I found digging in the dev tools.

Followed the instructions at https://support.mozilla.org/en-US/kb/storage

and yep; app.slack.com Storage 2.0 GB

Clearing it makes the site work again.

Would be good for firefox to not just fix this, but make sure that there is some communication around this kind of thing going wrong.

Because the layman's perspective here is "one site I rely on for work just stopped working in Firefox for no reason and without explanation or way to fix it."

You are an absolute godsend. I was getting this error on multiple various sites and this is slowly fixing the issue for a "layman" like me.
I got this for https://angular.io/ among various other sites.

I think it might be due to corruption somewhere in the firefox profile since I keep it on a USB and the other day the computer BSOD'd and the USB had quite a few file "corruption" according to chkdsk.

From reading the comments it looks like it relates to service worker. If there's a corruption or a bug or something in the service worker, it would be nice to be able to clear that more easily.

If you guys need anything from my profile (I haven't cleared everything and I think there are still sites failing) I should be able to send it over.

Comment 61

[Wayne Koorts]

I have recently started getting this error for a couple of sites, including Reddit. I haven't seen it before some time within the last couple of weeks, so it must have come with a recent Firefox release. When I looked at the site data according to the FF options, there was no data stored for Reddit. Regardless, I did a clear of all site data but no cookies. That didn't fix it. It was only when I cleared the cookies for Reddit that it started working again.

I am on Windows 10 Professional 20H2, Firefox 86.0 regular release channel. If there's anything I can do to help please let me know.

Comment 62

[Wayne Koorts]

I should also add: This does seem to be something which occurs over time (which initially made me think it could be storage-related). It's happened at least twice with Reddit. I actually don't visit Reddit very often from my desktop, and I don't ever leave it open in a tab while I'm not using it, if that helps.

A couple of weeks ago I did a complete reinstall of my system after getting an NVMe SSD. I only noticed the problems since the reinstall. Just letting you all know in case that could be a factor. Or some kind of Windows update; I always keep my system up to date as soon as Windows updates come out.

Comment 63

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I'm also experiencing comment 57 with mozilla.slack.com, but get a different error message. Putting it here to help folks find this bug (and no, my file system is not out of space):

Cache failure: 'Unavailable', file DBSchema.cpp, line 519 failed with result 0x80520010 (NS_ERROR_FILE_NO_DEVICE_SPACE)
Cache failure: 'Unavailable', file DBAction.cpp, line 210 failed with result 0x80520010 (NS_ERROR_FILE_NO_DEVICE_SPACE)
Cache failure: 'Unavailable', file DBAction.cpp, line 121 failed with result 0x80520010 (NS_ERROR_FILE_NO_DEVICE_SPACE)
Cache failure: 'Unavailable', file DBAction.cpp, line 88 failed with result 0x80520010 (NS_ERROR_FILE_NO_DEVICE_SPACE)
Error when attaching target: Error: Connection closed, pending request to server1.conn0.contentProcess8445/workerDescriptor12, type getTarget failed

Request stack:
request@resource://devtools/shared/protocol/Front.js:288:14
generateRequestMethods/</frontProto[name]@resource://devtools/shared/protocol/Front/FrontClassWithSpec.js:46:19
getTarget/this._attach<@resource://devtools/client/fronts/descriptors/worker.js:94:44
    baseFrontClassDestroy resource://devtools/shared/protocol/Front.js:99
    purgeRequests resource://devtools/client/devtools-client.js:690
    onPacket resource://devtools/client/devtools-client.js:481
    send resource://devtools/shared/transport/local-transport.js:68
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:103
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:103

Comment 64

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #63)

I'm also experiencing comment 57 with mozilla.slack.com, but get a different error message. Putting it here to help folks find this bug (and no, my file system is not out of space):

This is quota enforcement manifesting as lack of space to SQLite at the VFS level. Can you confirm that:

• When you say comment 57, you mean that you are seeing slack using 2.0GB of storage per the relevant about:preferences UI?
• Alternately, if you're not seeing 2.0GB of space used, is the free space available on the profile's block device/drive/partition less than 20GB? (:nika has reported a slight variation on this where our quota enforcement limit ends up being less than 2GB due to how we decide limits).

Comment 65

[Andrew Sutherland [:asuth] (he/him)]

So I think the heuristic for fixing this bug in conjunction with fixing the ServiceWorker lifecycle issue in bug 1668743 which is giving rise to Slack's runaway quota usage (due to the comment 54 behavior interacting with the bug) is:

• QuotaManager will track when an origin actively bumps up against its quota limit via a call to QuotaObject::LockedMaybeUpdateSize returning false. I will file a bug on this and link it here via edit.
  • This may want to be implemented as a counter so that logic can tell "did the origin bump up against the limit since I started paying attention" as opposed to "ever since the profile started".
• ServiceWorkers will pay attention to origins hitting this limit during:
  • Install / update jobs and during the "install" event. If the install/update fails and the quota limit was hit, we will assume the ServiceWorker is unable to self-heal from the quota problems and it needs our help by clearing the origin.
  • Navigation fetch requests that involve spawning the ServiceWorker where the interception fails via abort/NS_ERROR_DOM_ABORT_ERR or corrupted content. We clear the origin here too. This helps address:
    • Quota Shrinkage: The browser restarted and now the origin's quota is smaller than it was when it installed.
    • Fetch behaviors that cache as data is retrieved but potentially aren't aware of quota and/or are just naive.

Origin clearing would want to avoid clearing cookies. LocalStorage is a toss-up as it has its own very low hard quota limit and ServiceWorkers can't see LocalStorage so LocalStorage can't directly break a ServiceWorker.

Comment 66

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #64)

• When you say comment 57, you mean that you are seeing slack using 2.0GB of storage per the relevant about:preferences UI?

Yes. app.slack.com 2.0 GB.

Mac HD partition where firefox is installed has 326 GB free.

Comment 67

[vinc]

(In reply to vinc from comment #44)

Just to add as to the scope of this problem; I am not a heavy user of Slack, and not a very tech user nor a dev.

I found this bug page because I tried googling the NS_ERROR_DOM_ABORT_ERR error I found digging in the dev tools.

Followed the instructions at https://support.mozilla.org/en-US/kb/storage

and yep; app.slack.com Storage 2.0 GB

Clearing it makes the site work again.

Would be good for firefox to not just fix this, but make sure that there is some communication around this kind of thing going wrong.

Because the layman's perspective here is "one site I rely on for work just stopped working in Firefox for no reason and without explanation or way to fix it."

Hit this error again today, 2 months later.

Except it now manifested while I was having Slack open, and the Slack web app just kept saying 'Slack is offline'.

At first, assumed Slack was down. Turns out no one else has this problem.

Try opening slack in a new window.

No loading, no error, etc.

After a few frustrating hours, remembered this bug from 2 months ago.

Could we at least show an error when this happens?! like Masatoshi Kimura's suggestion:

(In reply to Masatoshi Kimura [:emk] from comment #47)

Regarding the "nothing happens" error, I recalled bug 1050329. I think we should at least show an error page.

Comment 68

[Victor]

It can be solved if you clean the cache data in FF: options -> search "manage data" -> slack (2.0GB) -> save changes
It got back to work in my case

Comment 69

[Wayne Koorts]

FYI I'm getting this like clockwork almost daily for Reddit at the moment, and it always only has just a few kB of storage used. Clearing cookies for reddit.com / www.reddit.com fixes it every time.

Comment 70

[fbessou]

FIW, I got the same problem on a matrix instance. Removing the site from `.mozilla/firefox/<profile-id>/serviceworker.txt solved the problem.

Comment 71

[Daniel Mota Leite]

Also had this problem right now, second time in the last 15 days. I do use pinned slack tabs

The first time i removed the 2GB of slack data and this time i tried to unregister the slack service. Both worked in solving the problem

Comment 72

[fbessou]

I have the same problem with open.spotify.com. The site works if I restart firefox after having changed the fetch flag to false in serviceworker.txt. Changing the fetch flag back to false make the problem come back.

Comment 73

[ger]

Same problem here for Firefox 87.0 (64-bit). The browser has problems with app.slack.com (NS_ERROR_DOM_ABORT_ERR in Network tab). It now consistently won't load. Willing to debug if necessary. When I use a different profile it loads fine, but the other profiles don't have the logged in session data so apples and oranges perhaps...

Comment 75

[Crystale]

This problem is happening to me since at least last week. I updated my Firefox Nightly with no success, I deleted Slack data with no success. I does work in private browsing.
OS: Xubuntu 18.04.5
Desktop environment: XFCE 4.12
Browser: Firefox Nightly 89.0a1 (2021-03-27) (64-bit)

Comment 76

[Mike Pennisi [:jugglinmike]]

I was also observing the NS_ERROR_DOM_ABORT_ERR for requests to app.slack.com. I hadn't reached the storage capacity reported in comment 40, and I was able to resolve through a different method. Is it possible that there are two different causes?

app.slack.com was using 163 MB of storage according to the Preferences page. That's much more than any other domain in my profile but also well below the 2GB threshold.

Instead of clearing all site storage, I visited about:serviceworkers (for those following along, type that directly into the browser's location bar), and unregistered the domain's service worker. This resolved the problem.

Firefox: 87.0 (64-bit)
Platform: Ubuntu 18.04.5 LTS

Comment 77

[Crystale]

Mike Pennisi procedure did the trick for me.

Comment 78

[Ash]

Deleted 2.0G of data from app.slack.com to solve this problem just to concur with this datapoint.

Comment 79

[me]

I also stumbled on this on web.telegram.org, this was 100% reproducible, with or without dev tools. Dev tools reported NS_ERROR_DOM_ABORT_ERR too.

But for me, the "Manage Data" UI showed that only 180 MB are occupied by web.telegram.org storage. There were only 597 MB left on my partition. Then, after I freed some space on my partition and rebooted Firefox, web.telegram.org worked again. This happened on Firefox 87.0 on Windows 8.1.

Comment 80

[scott]

Just to add a data point, I was getting the NS_ERROR_DOM_ABORT_ERR while loading Slack on Firefox 87, and unlike many people here, I was not at the quota limit of 2.0 GB of data. Only 285 MB of data for app.slack.com. In my case, unregistering Slack's service worker from about:serviceworkers (but not clearing the data) got Slack to load again.

Comment 81

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

In today's channel meeting, we agreed this issue should get its own support article. JR, can you take it from here?

Comment 82

[JR Johnson]

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #81)

In today's channel meeting, we agreed this issue should get its own support article. JR, can you take it from here?

Hi there. Yes I can take it from here. I will follow up with an update after speaking to our content writer.

Comment 83

[Ori Avtalion (salty-horse)]

(In reply to scott from comment #80)
Unregistering the service workers worked for me.

Comment 84

[JR Johnson]

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #81)

In today's channel meeting, we agreed this issue should get its own support article. JR, can you take it from here?

Created a draft documented for this sumo article and shared with you via internal message. Please review for any additional needed or missing content. This article will be ready to upload to SUMO for the 88 release.

Comment 85

[Evgeny]

(In reply to scott from comment #80)

Just to add a data point, I was getting the NS_ERROR_DOM_ABORT_ERR while loading Slack on Firefox 87, and unlike many people here, I was not at the quota limit of 2.0 GB of data. Only 285 MB of data for app.slack.com. In my case, unregistering Slack's service worker from about:serviceworkers (but not clearing the data) got Slack to load again.

Unregistering Service workers also fixed the issue for me for app.slack.com, and I also had little data (<50 MB). Firefox 87.0 on Windows 7 (but it's been happening off and on for a while with earlier versions).

Comment 86

[Hubert Wombacher]

got this error within office365 sharepoint links
other browser / private windows all worked
after removing cached cookies in Firefox i was able to access the site again
so looked like an exception during cookie loading for the very first request
browser was 88.0 (64-bit) Ubuntu canonical 1.0

Comment 87

[guerin45]

I got this error with my website the first time I enter the URL when a service worker is already installed, but the cache is empty.
The page appear when I refresh it.

While waiting for this bug to be fixed, I disabled the service worker in Firefox desktop, which is not very annoying since it still doesn't handle PWAs anyway...

Comment 88

[jomo]

I can confirm visiting about:serviceworkers and unregistering the service workers of the affected website gets rid of the issue.
I also remember getting rid of it in the past by fixing some broken sqlite files (using sqlite3's .recover) in the profile directory. Though I don't remember which files exactly and that method didn't work today.

Comment 89

[dvedvick]

(In reply to jomo from comment #88)

I can confirm visiting about:serviceworkers and unregistering the service workers of the affected website gets rid of the issue.
I also remember getting rid of it in the past by fixing some broken sqlite files (using sqlite3's .recover) in the profile directory. Though I don't remember which files exactly and that method didn't work today.

Clearing the service workers for Slack did the trick for me.

Comment 90

[christopher.guinnup]

Got a blank page when trying to access our company's Microsoft Sharepoint site. (NS_ERROR_DOM_ABORT_ERR in devtools.)
No service workers registered to the domain.
Clearing the site's cookie and storage data did resolve the issue. Only about 230 MB used, so not close to the 2 GB quota.
FF 89.0 on Windows 10.

Comment 91

[Vegard Nossum]

I'm also hitting this regularly with slack on Linux 89.0 (64-bit). The storage used was also some 200 M, but clearing it fixed the issue.

Comment 92

[Robert Borkowski]

(In reply to christopher.guinnup from comment #90)

Got a blank page when trying to access our company's Microsoft Sharepoint site. (NS_ERROR_DOM_ABORT_ERR in devtools.)
No service workers registered to the domain.
Clearing the site's cookie and storage data did resolve the issue. Only about 230 MB used, so not close to the 2 GB quota.
FF 89.0 on Windows 10.

I also started seeing this behavior on Sharepoint since around FF 88.0. It is still present in FF 89.0. After typing URL and hitting Enter, the page does not load at all (not even an error page from FF, the tab content effectively stays at about:blank). It took me some time to figure out to look into the Network Monitor and notice NS_ERROR_DOM_ABORT_ERR, and that's how I found this thread. After reading it, I tried unregistering the service worker for Sharepoint, and issue was solved for now. This seems to often kick in after FF crashes or when previous session is restored.

Comment 93

[Daniel Mota Leite]

I use umatrix, https everywhere and privacy badger, does everyone with this problem also use any of them? If yes, maybe this is related to something one of this add-ons is doing

i'm getting a similar problem also with https://discuss.prometheus.io/, first post i click works, but then new ones usually stop working. unregister the service fixes the issue for a few more clicks

Comment 94

[guerin45]

I use HTTPS everywhere, uBlock origin and NoScript

Comment 95

[Mike Pennisi [:jugglinmike]]

Firefox 89.0 (64-bit) (with no plugins installed) on Ubuntu 18.04.5 LTS exhibits a distinct but potentially related bug.

When visiting a Slack instance, most of the resources load, so unlike in previous comments, I can view some content. However, a number of resources fail to load (which interferes with the application's functionality) and the Network tab reports NS_BINDING_ABORTED.

I believe this may be related because the problem the steps in comment #76 are effective at correcting the problem. I'm happy to file a separate issue if folks think that's more appropriate.

Comment 96

[Wayne Koorts]

(In reply to Wayne Koorts from comment #69)

FYI I'm getting this like clockwork almost daily for Reddit at the moment, and it always only has just a few kB of storage used. Clearing cookies for reddit.com / www.reddit.com fixes it every time.

Update: I don't seem to have encountered this since v89.

Comment 97

[vinc]

Still getting this on Slack, on 89.0.2 (windows).

From a non-techie's perspective, this one site just stops loading without any error message from Firefox.

But it's easily fixed by the user themselves by going to https://support.mozilla.org/en-US/kb/storage

The browser really should show these instructions on encountering NS_ERROR_DOM_ABORT_ERR.

I love firefox and would start digging into dev tools, but an average user will just switch (back) to chrome.

Comment 98

[omcsesz]

I'm also having this bug for slack.com in Firefox 89.0.2 (64-bit).

Comment 99

[Eduardo Trápani]

This bug bites me every week or so with teams.microsoft.com. It took me a while to debug it because the error message is completely misleading.

Removing all storage for teams.microsoft.com make it work again, flawlessly.

Firefox 89.0.2 (64-bit) Linux. Teams.microsoft.com was using 180M of storage and the whole storage folder for the profile was using 287M.

Is there any other workaround besides manually removing the storage when the site starts to misbehave? (also voice calls stop working).

Comment 100

[Eduardo Trápani]

This is still happening in 89.0.2, see comment #98 and comment #99

Comment 101

[bastien]

It still occurs on 89.0.2 linux 64.
Each time on https://app.slack.com/ until I reset local storage.

Comment 102

[Nicholas Fish]

I'm also seeing this on Firefox 89.0.2 in x86_64 Linux for Slack. Storage is 817 MB. Clearing storage as suggested re-enables the site.

Comment 103

[Rob Wagner]

Firefox 89.0.2 - I also experienced this error with my school's Sharepoint site. Clearing a couple hundred MB of site data solved the problem after repeated efforts lead me to this page.

Comment 104

[Anatoli Babenia]

As an original author of this bug report, I am unsubscribing from this thread. Too many notifications. So don't count me as an issue owner anymore.

Comment 105

[Andrew Sutherland [:asuth] (he/him)]

Mitigations for this problem in bug 1503072 landed on mozilla-central last night and are present in today's 20210713032526 nightly. The mitigation should automate bypass of failed ServiceWorker navigation fetches including this dreaded NS_ERROR_DOM_ABORT_ERR error. We're going to let it bake on nightly and then pursue uplift to beta if there are no surprises.

Bug 1720410 has been spun off to cover the next steps of the mitigation as discussed in bug 1503072 comment 20, namely the automatic removal of apparently broken registrations and origin/group clearing. Please see the lengthy comment there for more information on this.

Bug 1668743 continues to exist to track the more complicated life-cycle improvements that need to be made to avoid creating some of the situations that result in these mitigations being necessary.

Comment 106

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Do users still observe the issue or can the bug be closed?

Comment 107

[Andrew Sutherland [:asuth] (he/him)]

Given that Firefox 93 is currently the released version of Firefox and it includes the last of the planned mitigations for this bug, I'm going to call this RESOLVED FIXED. If anyone is continuing to experience similar failure modes to those originally documented here (seeing a completely blank tab with a possibly empty URL bar), it would be most ideal if you could file a new bug with full details (in order to avoid the many people on the CC list), but if not, please do chime in here on the bug.

The mitigations that landed and when they shipped:

• Bug 1503072 - Resets interception on failure - Landed in Fx92, uplifted to Fx91
• Bug 1720410 - Removes faulting registrations after multiple resets - Landed in Fx92, uplifted to Fx91
• Bug 1722502 - Clears origin/group storage when faulting if we believe the origin/group may be hitting their quota limits and are unable to address this problem on their own. - Landed in Fx93.

Many, many, many thanks to Eden for taking over my initial buggy set of mitigations, identifying the cause of the problems, and then iterating to produce our extensive set of mitigations that we now have in place!