Specify 7.11.3 (though problem has been happening since 7.9.5 at least)
Specifically when using Specify 7 in Firefox (multiple versions, currently on v. 145.0.2 (aarch64)).
This post describes a recurrent problem I’ve experienced on multiple computers, but haven’t written it up til now because it’s a minor annoyance. I’d say it happens to me probably at least once per day, somewhat randomly, though certain actions/conditions tend to trigger it.
When I have a few tabs (usually 6-10, but I’ve had it happen with as few as 2 tabs) open of Specify 7, sometimes the page I’m on will freeze (buttons won’t react, browser commands like back/refresh don’t work). This happens especially frequently when one of the tabs has a tree open, and happens especially frequently when there are two tabs open to a tree. When this happens, all other Specify 7 pages freeze too. All other browser tabs, if any non-Specify pages are open, are functional and have no issues. Usually, my computer fans start running shortly after the freeze starts. The only way to fix this issue is to close all Specify 7 tabs. There is never an error message, the pages simply become completely unresponsive.
I have noticed that if I look at CPU activity in macOS when the freeze is happening, Specify Firefox tab processes collectively take up all available resources on whatever machine I’m using.
I’ve also noticed that when opening a new Specify 7 tab after closing all frozen ones, the page loads with the spinning wheel icon which usually means that the server has restarted, which suggests that part of this could actually be a server-side rather than client-side problem
I haven’t seen this issue in Chrome or other browsers, but I don’t use them frequently enough to be sure it only happens in Firefox.
It’s very difficult to reproduce this on command. The only time I’ve ever forced it to happen was by opening a large number of tree tabs and attempting to upload an attachment record to a CO via the dialog window on the CO form.
I’m curious to know if anyone else experiences this.
Specify Team: Is there anything I can do / record in-browser the next time this occurs to help get to the bottom of what’s happening?
I had this issue again today and managed to record a profile log of it in firefox. I only had a few firefox tabs open, but clicking the collecting event attachment button on a record froze all of the tabs and initiated a super CPU intensive process on my machine.
Seems like performing certain actions in the GUI can trigger a feedback loop when there are concurrent tabs open in Firefox.
It’s a way over my head to understand precisely what’s going on, but the affected Firefox process, in a 5-second time window, completed: 4,253 storage events, 3,862 change events, 570 Firefox internal MozLocalStorageChanged events, in total about 7.05 GB of JavaScript allocation.
I believe, at a minimum, the problem you encountered with tree syncing will be solved in the 7.12.1 update, which is in the testing phase now. We still recommend the use of Chrome or a Chromium-based browser, but this issue can happen in either browser.
It looks like the issue you encountered is the same one described here:
Currently, Specify can get stuck trying to load two different positions in the tree at the same time, which causes memory and CPU usage to increase exponentially until the browser becomes unresponsive.
We’ve pushed a fix for this that makes sure the URL functions as the source of truth for the tree rather than playing a game of catch-up ad nauseam and possibly freezing the browser.
This fix may solve the most recent issue you encountered as well with the Collecting Event Attachment button, but our team will attempt to recreate this and let you know if we can confirm that solution.
Would you be willing to provide us with a backup and the steps you followed before clicking on the attachment button? I have tried to recreate the issue on /specify/view/collectionobject/502121/ but have not had success on either Firefox or Chrome.
If that is not possible, we will do our best based on the information provided!
Thanks for this @Grant!
Notably – this time around i had no tree tabs open at all. The initiation of the bug was upon attempting to open a collecting event attachment. Prior to clicking, the app was behaving normally.
I think it might have something to do with concurrent saved and unsaved form states when different linked records are open.
I will send you guys a backup and also the nginx logs from prior to the runaway tab problem.
Excellent, thank you for the clarification and the steps! Once we receive a backup, we’ll debug this closely and hopefully draft a solution to the problem.
Here to report back after testing the backup you shared in Firefox!
I was able to recreate the freezing behavior when there were multiple (6+) tree tabs open and clicking through nodes across those tabs. This aligns with what you describe in your original post:
It’s very difficult to reproduce this on command. The only time I’ve ever forced it to happen was by opening a large number of tree tabs and attempting to upload an attachment record to a CO via the dialog window on the CO form.
However, I saw error messages and was able to download a crash report. In a test with 5 tree tabs and fewer requests, I received an error message in each of the unresponsive tabs after little to no idle time (<3 min). In another test with 7 tree tabs and more requests, I was able to see the same error message but it couldn’t be downloaded due to the level of overwhelm. The error message is "QuotaExceededError: The quota has been exceeded.","stack":"\nye@https://invertebratesosu20260730-v7.test.specifysystems.org/.
The QuotaExceededError was sent because Specify was exceeding the maximum amount of storage allotted by Firefox.
I’ve learned that Specify stores a handful of things in the browser, including:
Collection and User Preferences
Dialog size and placement
The last time a stats request was sent
Which nodes are expanded and focused in the tree viewer
Given that the issue occurs when there are many dialogs and/or tree viewer tabs open, this makes sense! The level of customization to the statistics page and preferences in the instance also raises the baseline amount being stored.
I tested a solution from this Mozilla ticket and believe that increasing the amount of storage should resolve this for you. To do that:
Enter “about:config” in the address bar
Search for “dom.storage.default_quota”
Edit value and enter larger value
I could no longer raise the QuotaExceededError after increasing it to 85000.
Please give that a try on your end and let us know how it goes!
Bronwyn,
Amazing, wasn’t expecting a test/answer for this so soon! I’ve changed this setting and will let you know if i keep encountering this issue.
It’s interesting that you got an error message, as that has never happened in my experience, it always just freezes without a prompt.