Open Bug 1647323 Opened 2 years ago Updated 3 months ago

firefox storage breaks, causing addons to misbehave

Categories

(Core :: Storage: Quota Manager, defect, P3)

77 Branch
defect

Tracking

()

People

(Reporter: rossen, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached video firefox_broken.mp4

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

Steps to reproduce:

I've already look at https://bugzilla.mozilla.org/show_bug.cgi?id=1536796 and used the glitch site from there. For me this issue causes umatrix addon to stop working correctly and prevent any site from loading. See https://github.com/uBlockOrigin/uMatrix-issues/issues/269

Minimum steps to reproduce:

  1. Use blank profile, open https://firefox-storage-test.glitch.me/ (all green)
  2. Open youtube.com
  3. Close and re-open firefox
  4. Load https://firefox-storage-test.glitch.me/ - get errors
  5. Close Firefox
  6. Remove youtube folder from C:\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\storage\default
  7. Start firefox, open https://firefox-storage-test.glitch.me/ - all green

See video attached.

Actual results:

Storage is broken

Expected results:

Everything should work

Thanks for reporting this! We are working on this in bug 1645943.

The issues for having a storage of a site that end with a dot break add-ons should be fixed once we land D79959, and D80001. In other words, the add-ons should stop being broken once we land these two but we still have issues in FQDN sites themselves.

The issue for the storage of sites that end with a dot should be fixed in D80202.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1645943

Wait, I actually misunderstood this. You went to "https://youtube.com" rather than "https://youtube.com."

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---

Hi Tom, this one has nothing to do with . at the end. Simply going to any website that uses storage causes the issue to appear.

Hi Rossen,

It looks really bad. I'm sorry about this.

A few questions:

  • In "about:config", if you set dom.quotaManager.useDOSDevicePathSyntax to false and then restart the browser, can you still reproduce the issue? That should help us to understand if it's related to \\?\ prefix stuff.

  • In "about:config", if you set network.file.disable_unc_paths to false while setting dom.quotaManager.useDOSDevicePathSyntax to true and then restart the browser, can you still reproduce the issue?

  • Could you run a debug build and share the log here or email me directly? That would help us to find the issue sooner.

Flags: needinfo?(rossen)
Assignee: nobody → ttung
Severity: -- → S2
Status: REOPENED → NEW
Component: Untriaged → Storage: Quota Manager
Priority: -- → P2
Product: Firefox → Core

Hi Tom, trying the suggested setting makes no difference. I am unable to run the debug build as I don't have full control over the device. What will the debug build do? I can look into how I can run it.

(In reply to Rossen from comment #5)

Hi Tom, trying the suggested setting makes no difference.

Then, it seems it's not related to bug 1536796 at least at the moment.

I am unable to run the debug build as I don't have full control over the device. What will the debug build do? I can look into how I can run it.

It would enable debug assertions and pipe warning messages that generated from our code to a console. If we have that, we can find where unexpected things start to happen.

For instance, the message looks like: [11455, Main Thread] WARNING: '!window', file /xxx/Work/mozilla-central/dom/cache/CacheStorage.cpp, line 571. With this, we can know it happens on which line of code and thus figure out the issue quickly.

Base on the information so far, something unexpected might happen around:
https://searchfox.org/mozilla-central/rev/3d39d3b7dd1b2be30692d4541ea681614e34c786/dom/quota/ActorsParent.cpp#2557,2601

We create ".metadata-v2-tmp" at line 2557 and rename it to ".metadata-v2" line 2601.

Unassign me and set the priority to a lower number since it's not easy to work on this without further information and I cannot reproduce this).

I'm happy to work on this again or help someone else to work on this once we have more information or if they can reproduce the issue.

Assignee: ttung → nobody
Priority: P2 → P3

Hi Rossen,
I did not manage to reproduce this issue on the latest Firefox Nightly 88.0a1 on macOS 10.15. Could you please check it out once more on the latest Firefox version?

The bug still happens for me on v85. Unfortunately, our security team has not made progress on allow me to run a debug build of Firefox to get more information.

Flags: needinfo?(rossen)

(In reply to Rossen from comment #10)

The bug still happens for me on v85. Unfortunately, our security team has not made progress on allow me to run a debug build of Firefox to get more information.

If it's not possible to run with a debug build, then would it be possible to run with Nightly and share the log in the browser console?

After Bug 1660751, we should be able to see storage's error logs to the console on Nightly and early Beta. Note that, please remember to make a copy of your profile and run Nightly with the copied profile. Because we don't support profile downgrade in general.

Blocks: 1482662

Hi Rossen, while it seems we were inactive on this bug actually quite some progress has been done in this area in general. Are you still experiencing this issue and if yes, with which version? Thanks for your support.

Severity: S2 → S3
Flags: needinfo?(rossen)

I can confirm this still happens on latest release. I'm sorry I can't troubleshoot this further due to the restriction on the workstation by our security team. It is plausible this is caused by endpoint protection software.

Flags: needinfo?(rossen)

(In reply to Rossen from comment #13)

It is plausible this is caused by endpoint protection software.

That sounds plausible, yes.

(In reply to Tom Tung [:tt, :ttung] from comment #11)

If it's not possible to run with a debug build, then would it be possible to run with Nightly and share the log in the browser console?

This would be still a path forward to further investigate, it might give also indications to your admins what is actually going wrong. Thanks for your support!

Flags: needinfo?(rossen)
You need to log in before you can comment on or make changes to this bug.