Closed Bug 1622762 Opened 4 years ago Closed 2 years ago

Firefox refuses to connect to some websites (IndexedDB UnknownErr)

Categories

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

Product:
Core
Component:
DOM: Service Workers
Version:
74 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: github, Unassigned)

References

Details

Attachments

(2 files)

ff-storage-test.png
25.08 KB, image/png
Details
storage-test_v98
39.44 KB, image/png
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Happening on 2 different PCs with Sync enabled between all of them.

PC1: Trying to open reddit.com, web.telegram.org or web.whatsapp.com
PC2: Trying to open reddit.com or web.whatsapp.com (web.telegram.org works)

Actual results:

Literally nothing.

When opening a new tab and typing "http://reddit.com" into the adressbar, Firefox will go to about:blank and the URL "http://reddit.com" is visible in the addressbar.

When clicking a link that points to the mentioned domains, the following happens:

  • From about:newtab, the page changes to about:blank and the addressbar is empty. Network analyser doesn't register anything (stays empty).
  • From anywhere else (like googling "reddit" and clicking the first link), the website-icon will change to the loading-icon and instantly switches back to the previous websites icon. Network analyser doesn't register anything (no new entries).

On my Firefox for Mobile on my smartphone (also Sync-enabled), everything works fine.

Expected results:

The respective website should be displayed.

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

Component: Untriaged → New Tab Page
Component: New Tab Page → Address Bar

Forgot to mention: This also happens in safe mode.

See Also: → 1621301

What does your network look like? Are you using a custom DNS? Do any errors appear in the browser console when this happens?

Flags: needinfo?(github)

This is from bug 1621301 comment 12:

The firefox users in these questions did a Firefox Refresh and/or cleared the cache and cookies for the affected websites and the issue went a away after that.

If you try that, does it fix it?

Nope, no custom DNS and no errors. Clearing.cache and.cookies didn't help either.
I've also tried "forget entire website" from the history.

Other applications, browsers and Firefox-Profiles can access these websites without problems.

Networks aren't anything special. On PC1 it's a company LAN that I manage. On PC2 it's a private connection at home.

Flags: needinfo?(github)

If you refresh Firefox, does that help? Go to about:support and click the Refresh Firefox button at the top right.

Other than that, I'm not sure what more to do about this. This sounds like bug 1621301. I doubt it's really a problem with the address bar but more likely something deeper in Firefox related to document loading. I haven't seen any other similar bugs filed recently aside from bug 1621301 and other bugs commented on there. We can keep an eye out for other similar bugs filed in the future.

Priority: -- → P5

I think I managed to get it working again.

I wasn't keen on losing my Add-Ons and Browser-Settings, so I looked through the links that bug 1621301 referenced.
While Firefox was closed, I deleted all folders that have to do with WhatsApp inside the storage folder. This made WhatsApp web work again in the affected browser.
I'll try the same tomorrow on the other affected PC and will report back.

(In reply to Snowman25 from comment #7)

I'll try the same tomorrow on the other affected PC and will report back.
It didn't work on the other affected PC.
I've tried refreshing Firefox by making a copy of my profile, but after that I noticed that it basically just makes a new profile and deletes the old one, so that is not satisfactory. It did restore access to the websites, though (just like a new profile did).

What other files are there that I might be able to delete to fix this? Or DB-Files that might store data on these sites that prevents Firefox from navigating to them?

FIXED IT:

While Firefox was closed, I deleted all entries of non-working websites in the following files:
serviceworker.txt
SiteSecurityServiceState.txt
After that and the previous mentioned steps (deleting according folders in the storage folders, all the websites work again.

The reason why this can be blocking should be checked. From a cursory glance, the entries didn't seem corrupted. They looked that same as other entries in these files.

I forgot to make a backup of these files beforehand, so I can't provide you with that information.

All right, this doesn't need to be in Address Bar anymore. Given the files you mention, I'll move this to Core::General and hopefully someone there will know where to direct it.

Component: Address Bar → General
Priority: P5 → --
Product: Firefox → Core
Component: General → DOM: Service Workers

(In reply to Snowman25 from comment #9)

FIXED IT:

While Firefox was closed, I deleted all entries of non-working websites in the following files:
serviceworker.txt
SiteSecurityServiceState.txt
After that and the previous mentioned steps (deleting according folders in the storage folders, all the websites work again.

The reason why this can be blocking should be checked. From a cursory glance, the entries didn't seem corrupted. They looked that same as other entries in these files.

I forgot to make a backup of these files beforehand, so I can't provide you with that information.

Hi Snowman25, did you by chance save the files before changing them? Would you mind to make them available (also through a more private channel) ?

Flags: needinfo?(github)

(In reply to Jens Stutte [:jstutte] from comment #11)

Hi Snowman25, did you by chance save the files before changing them? Would you mind to make them available (also through a more private channel) ?

Sorry, I neither have copies of the profile nor a shadow-copy of the files.
I'd recommend some fuzzing on single lines for testing, as an invalid state in these files should never lead to non-working websites. Worst case should be that the according entries get deleted and the according Workers, HSTS-Entries get recreated. I understand that this could be an issue with HSTS-entries, which are supposed to be permanent, but as long as an entry can't be invalidated remotely, I don't see a security vulnerability here.

Flags: needinfo?(github)

Without STR or forensic data it is a bit difficult to guess what to look at here. It is not said, that the files were corrupted by themselves but pointed to something weird in the profile or elsewhere. Andrew, any idea how to make this actionable?

Flags: needinfo?(bugmail)

It sounds like the general problem here is a failure mode where ServiceWorker interception occurs and hangs without either providing a valid response or resulting in the corrupted content dialog at bug 1503072.

My best current theory is that QuotaManager became broken in this profile and that the removal of the directories in question from PROFILE/storage/ un-broke QuotaManager.

Comment 5 references using History's "Forget about this site" (I'm assuming "forget entire website" was approximately quoted from memory) and the problem continuing even after this. I just locally used "Forget about this site" on nightly and it was able to successfully clear the whatsapp ServiceWorker the site had installed, so this would lead me to believe that QuotaManager was broken. A broken QuotaManager would fail to clear the data, perpetuating the problem.

The fact that Snowman25 performed a targeted removal of whatsapp directories and this fixed the problem suggests the problem was in the whatsapp origin directory, suggesting a potentially deterministic problem. The primary question would be whether this is something like the long path problem which could involve a long IndexedDB database name, or if it's something emergent from API usage somehow.

Snowman25, could you check how long the base of your profile path is? If you go to about:support and locate the Profile Directory table row under Application Basics. On Windows we store files in two locations, but that should be the roaming profile path which is the right location this case. Right-click on the path's text and choose "Inspect Element". This will bring up devtools. Then type $0.textContent.length in the devtools window and hit enter and it should provide a number that's the length of the path.

Flags: needinfo?(bugmail) → needinfo?(github)

Hello Andrew,
the Paths are 74 and 81 characters long (different computers with different profile-names).

Flags: needinfo?(github)
Priority: -- → P3

(In reply to Snowman25 from comment #16)

the Paths are 74 and 81 characters long (different computers with different profile-names).

Thanks for having answered this promptly; I did process your response but failed to respond at the time. Long file path breakage was the most likely explanation for what was happening, but it sounds like this was not the case. (Also note that fixes for that family of problems landed in bug 1536796 the next day, targeted at Firefox 76.)

Has the problem resurfaced for you at all since then and/or do you see any red/error responses if you browse to https://firefox-storage-test.glitch.me/ ?

Flags: needinfo?(github)
Attached image ff-storage-test.png —

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

Has the problem resurfaced for you at all since then and/or do you see any red/error responses if you browse to https://firefox-storage-test.glitch.me/ ?

I stumbled upon another website that has this problem for me: computerbase.de
The output of https://firefox-storage-test.glitch.me/ is in the attachement.

I haven't attempted to fix the glitch for computerbase.de yet, so I can provide files, if necessary.

Flags: needinfo?(github)

Thank you for providing that information. The site's results suggest that your profile's QuotaManager storage is broken such that any site that uses a ServiceWorker may in turn be broken. That is, the site that's failing to load may not be the site causing the problem. (Unless you're saying when you move the computerbase.de directory out of the PROFILE/storage directory that the problem is solved, in which case it's definitely that directory.)

When you first start-up Firefox, if you bring up the browser console via "ctrl-shift-J" or found under the "Web Developer" menu as "Browser Console", do you see any errors that start with "Quota:"? They will be categorized as errors, so you can click on the categories to the right of "Error" in the UI to toggle them off.

The Quota warning is probably the fastest thing, but if you identify any directories with problems, please feel free to zip them up and send them to me at asuth@mozilla.com and I'll take a look.

Flags: needinfo?(github)

Hello Andrew, I did some testing:

  • Starting Firefox with the console open doesn't show any messages with "quota" in them.
    There are some messages relating to IndexedDB, however. Namely: 
    • IndexedDB UnknownErr: ActorsParent.cpp:612 (a total of 25 times)

    • UnknownError: The operation failed for reasons unrelated to the database itself and not covered by any other error code.	ExtensionStorageIDB.jsm:812
  normalizeStorageError resource://gre/modules/ExtensionStorageIDB.jsm:812
  method chrome://extensions/content/child/ext-storage.js:273
  AsyncFunctionThrow self-hosted:700
    • Lots of Warnings like the following for different extensions: 
      • 1589183363974	addons.webextension.snaplinks@snaplinks.mozdev.org	WARN
  Loading extension 'snaplinks@snaplinks.mozdev.org': JSONFile backend is being kept enabled by an unexpected IDBBackend failure:
  The operation failed for reasons unrelated to the database itself and not covered by any other error code.::
  • renaming the folder in PROFILE/storage/default doesn't result in the website starting to work again (Added an underscore in front)
  • Firefox Storage Test still shows exactly the same result.

Using Firefox 74.0 (32-Bit) with BuildID 20200309095159

Flags: needinfo?(github)

Jan, thoughts?

Flags: needinfo?(jvarga)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3
Summary: Firefox refuses to connect to some websites → Firefox refuses to connect to some websites (IndexedDB UnknownErr)

Hi Snowman25! We landed in the meantime many improvements regarding Quota Managers initialization. Do you still see this happen? Thank you for your support!

Flags: needinfo?(jvarga) → needinfo?(github)
Attached image storage-test_v98 —

Hi Jens!

see the attached output from Storage Test. No more errors!
I haven't checked it in the meantime though, so I can't say in which version it was fixed.
It was bad in v74 and some form of persistent record was able to be created in v75. I'm not sure if that has been consistent in that version though. Right now it seems to be stable and working just fine.
Computerbase.de is also working fine now.
Seems to be resolved.
Thanks!

Flags: needinfo?(github)
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: