1647323 - firefox storage breaks, causing addons to misbehave

Status: RESOLVED INCOMPLETE

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

Description

[Rossen]

Attachment: 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

Comment 1

[Tom Tung [:tt, :ttung]]

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.

Comment 2

[Tom Tung [:tt, :ttung]]

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

Comment 3

[Rossen]

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.

Comment 4

[Tom Tung [:tt, :ttung]]

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.

  • You can find a debug build for x64 Windows at https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&selectedTaskRun=PDRX2zW8RO6bvU59Pcy0BA.0
  • Find "Job Details" section in the panel below
  • Download the "target.zip" and run the firefox inside

Comment 5

[Rossen]

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.

Comment 6

[Tom Tung [:tt, :ttung]]

(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.

Comment 7

[Tom Tung [:tt, :ttung]]

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.

Comment 8

[Tom Tung [:tt, :ttung]]

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.

Comment 9

[Timea Cernea [:tbabos][inactive]]

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?

Comment 10

[Rossen]

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.

Comment 11

[Tom Tung [:tt, :ttung]]

(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.

Comment 12

[Jens Stutte [:jstutte]]

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.

Comment 13

[Rossen]

Attachment: firefox_97_storagebug.png

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.

Comment 14

[Jens Stutte [:jstutte]]

(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!

Comment 15

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.