NS_ERROR_FAILURE after updating to Firefox Developer Edition 87.0 Beta 3 (20210225185804)
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: heikki, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
It seems like the latest beta version of Firefox Developer edition has a problem with AJAX calls. My computer updated this morning to Firefox Developer Edition 87.0 Beta 3 (20210225185804) and since there I haven't been able to use most of the websites I use daily.
The symptons are similar everywhere. When browsing the websites, the console reports the following error with different Javascript codes.
Uncaught
Exception { name: "NS_ERROR_FAILURE", message: "", result: 2147500037, filename: "script.js.js", lineNumber: 30, columnNumber: 0, data: null, stack: "attach/<@script.js.js:30:43\neach@jquery.min.js:2:2976\neach@http://example.com/core/assets/vendor/jquery/jquery.min.js?v=3.5.1:2:1454\nattach@script.js.js?v=8.9.13:28:66\<@script1.js.js:25:24\nDrupal.attachBehaviors@script1.js.js:22:34\n@script1.js.init.js:28:12\nlistener@script1.js.init.js:20:9\n" }
The script giving errors varies but the result is the same that almost all JS functionalities are broken.
|
||
Comment 1•5 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•5 years ago
|
||
NS_ERROR_FAILURE indicates some error outside of SpiderMonkey, so back to "Untriaged" for now.
In the original bug report there is an accidental mention of a project address [removed]. Could these parts be removed from the bug report since they are sensitive information?
Also related to the original bug report. I noticed that opening a page in a private window, the error disappears. I suspected some add-on misbehaving after the update but disabling all addons does not solve the issue.
One page which is giving me problems is https://mmenujs.com/. The hamburger menu on the top left corner does not open by default and I get the following console error:
Uncaught
Exception { name: "NS_ERROR_FAILURE", message: "", result: 2147500037, filename: "https://mmenujs.com/mmenu/mmenu.js?v=8.5.0", lineNumber: 12, columnNumber: 0, data: null, stack: "sidebar@https://mmenujs.com/mmenu/mmenu.js?v=8.5.0:12:28637\nS</e.prototype._initAddons@https://mmenujs.com/mmenu/mmenu.js?v=8.5.0:1:7844\ne@https://mmenujs.com/mmenu/mmenu.js?v=8.5.0:1:3616\n@https://mmenujs.com/js/layout.js?v=8.5.0:1:1207\n@https://mmenujs.com/js/layout.js?v=8.5.0:1:2462\nj@https://code.jquery.com/jquery-3.2.1.min.js:2:29999\ng/</k<@https://code.jquery.com/jquery-3.2.1.min.js:2:30313\n" }
Clicking on the hamburger does not nothing.
Page works fine in private window.
|
||
Comment 5•5 years ago
|
||
(In reply to heikki from comment #3)
In the original bug report there is an accidental mention of a project address [removed]. Could these parts be removed from the bug report since they are sensitive information?
Done. Removing the security flag again as this doesn't look like a security issue.
(In reply to heikki from comment #3)
Also related to the original bug report. I noticed that opening a page in a private window, the error disappears. I suspected some add-on misbehaving after the update but disabling all addons does not solve the issue.
I'm assuming you manually disabled add-ons. Does using "Help > Restart with add-ons disabled" fix the issue?
Also, are you in a position to use mozregression to narrow down what broke this? ( https://mozilla.github.io/mozregression/ ; you can pass it the path to your current profile where you're seeing the issues and ask it to clone the profile for tests (should be the default))
Moving to DOM land as this looks like an internal XPCOM error leaking into DOM land which likely involves some DOM API or other.
(In reply to heikki from comment #3)
Also related to the original bug report. I noticed that opening a page in a private window, the error disappears. I suspected some add-on misbehaving after the update but disabling all addons does not solve the issue.
I'm assuming you manually disabled add-ons. Does using "Help > Restart with add-ons disabled" fix the issue?
Starting in Safe mode with addons disabled does not fix the issue.
Also, are you in a position to use
mozregressionto narrow down what broke this? ( https://mozilla.github.io/mozregression/ ; you can pass it the path to your current profile where you're seeing the issues and ask it to clone the profile for tests (should be the default))Moving to DOM land as this looks like an internal XPCOM error leaking into DOM land which likely involves some DOM API or other.
I can see if I can test that. No previous experience from that tool.
|
||
Comment 7•5 years ago
|
||
This is an important bug to fix, but rather difficult without steps to reproduce or regression range.
Not sure if if it is related but I am using macOS Big Sur 11.2.2.
I tried to use mozregression tool to test the problem but it seems like I am not able to run on it Big Sur.
It seems to start and then hangs and nothing happens. There seems to be a related issue for Big Sur Beta 4 at https://bugzilla.mozilla.org/show_bug.cgi?id=1650612.
Unfortunately my skills with Python are lacking.
Tested again with beta 5 and still the same problem.
Both with and without safe mode.
|
|
||
Comment 10•5 years ago
|
||
(In reply to heikki from comment #8)
Not sure if if it is related but I am using macOS Big Sur 11.2.2.
I tried to use mozregression tool to test the problem but it seems like I am not able to run on it Big Sur.
It seems to start and then hangs and nothing happens. There seems to be a related issue for Big Sur Beta 4 at https://bugzilla.mozilla.org/show_bug.cgi?id=1650612.
Unfortunately my skills with Python are lacking.
Can you try running the commandline version of the tool instead of the gui version, if the gui version is broken? pip install mozregression followed by mozregression --help should be able to help with that, as would https://mozilla.github.io/mozregression/documentation/usage.html .
|
Reporter | |
Comment 11•5 years ago
|
||
It seems like I was able to run mozregression in command line but I was not able to reproduce the bug yet.
Currently I ran the tool with the following settings:
mozregression --good=87.0b2 --bad=87.0b5 --arg="mmenujs.com/" --profile="/Users/<username>/Library/Application Support/Firefox/Profiles/yeuguk0q.dev-edition-default"
It seems like both versions are running the mmenujs.com site correctly and no errors in console. The profile seems to load fine because my own add-ons are visible and disabled like they should be.
I would probably need further help how to use the tool to debug the issue.
|
|
Reporter | |
Comment 12•5 years ago
|
||
Seems like the problem fixed itself while I was debugging the issue with mozregression.
When I started mozregression tests with my profile it complained about some files in my current profile under storage.
I copied the files from the /Users/<username>/Library/Application Support/Firefox/Profiles/yeuguk0q.dev-edition-default/storage/default to a temporary location to get the mozregression tool running.
Now when I reopened Developer edition it seems like everything is working again.
|
|
||
Comment 13•5 years ago
|
||
(In reply to heikki from comment #12)
Seems like the problem fixed itself while I was debugging the issue with mozregression.
When I started mozregression tests with my profile it complained about some files in my current profile under storage.
I copied the files from the /Users/<username>/Library/Application Support/Firefox/Profiles/yeuguk0q.dev-edition-default/storage/default to a temporary location to get the mozregression tool running.
Now when I reopened Developer edition it seems like everything is working again.
This smells like a DOM storage problem, then... :asuth, do you have ideas of what could cause this kind of breakage?
|
||
Comment 14•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #13)
This smells like a DOM storage problem, then... :asuth, do you have ideas of what could cause this kind of breakage?
This was likely QuotaManager and/or LocalStorage NextGen (LSNG) breakage due to the unexpected files? LSNG is enabled on EARLY_BETA_OR_EARLIER which I think is always on for dev edition? The mmenujs code is using localStorage but not IndexedDB or the Cache API, so that leaves it as pretty much the only thing storage related that could break.
There have been extensive and ongoing fixes in this area that are informed by telemetry event data that allows precise backtraces to be derived from telemetry, ex: https://bugzilla.mozilla.org/show_bug.cgi?id=1482662#c33. As such it might make sense to resolve this bug WORKSFORME now that the profile issue has been addressed and since the work on that bug is already able to gather this data automatically?
Description
•