Handler function threw an exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITraceableChannel.setNewListener]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame
Categories
(DevTools :: Netmonitor, defect, P5)
Tracking
(Fission Milestone:M7, firefox86 fixed)
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | fixed |
People
(Reporter: bugzilla, Assigned: ochameau)
Details
(Whiteboard: dt-fission-m3-mvp)
Attachments
(2 files)
|
||
Comment 5•7 years ago
|
||
@Michal: should we change the component to Networking?
Honza
|
|
||
Updated•7 years ago
|
|
||
Comment 7•7 years ago
|
||
There's too many potential causes here. Given the exceptions in comment 4 I'm guessing it's an extension issue, but which one? I'd first try in "safe mode" (disabling all customizations) and see if it happens -- you did say something about "site hosted" userscripts, and I don't know what that means but try that first on a plain Firefox. Then add your addons back one at a time to see if you can identify a particular combination where this happens.
I'm not saying it's not a Firefox bug, but we have to be able to reproduce it to investigate it. your listed symptoms aren't specific enough on their own.
The CSP comments that only happen on Bugzilla don't seem relevant to your original symptoms, and those were the only things that tie into "DOM: Security".
While I can't provide much in the way of what is causing it beyond what I have reported, as you can see it is very vague and hard to narrow down; I can assure that it is NOT an extension problem, at least not one installed by the user, it may be an extension issue that is related to the force included extensions globally that user can't manage or see even at times.
But so far as we can say the Mozilla globally forced extensions are not the issue, then it is not the issue with other extensions either, since I have tested this and gotten it on a clean created profile with absolutely NOTHING changed from out of the box defaults and you get this. So a fair assumption that it is the browser; however, where? I have no clue.
PS. Yes the CSPs were not related to my issues, just something I saw and as noted, reported it as interesting weirdness, not as supporting the original issue.
BTW, as of yesterday update to 64.0.2, it is still happening, wasn't sure if I should update the branch on the bug or not, so if someone feels it is appropriate, please make the change or let me know. Thanks.
|
||
Comment 10•6 years ago
|
||
Because of the nature of the bug and how generalized it is, I'm going to move this off of Untriaged and onto General. If you can nail something a bit more specific, we can try and redirect this to a more specific component.
|
||
Comment 13•6 years ago
|
||
(In reply to GµårÐïåñ from comment #8)
While I can't provide much in the way of what is causing it beyond what I have reported, as you can see it is very vague and hard to narrow down; I can assure that it is NOT an extension problem, at least not one installed by the user, it may be an extension issue that is related to the force included extensions globally that user can't manage or see even at times.
But so far as we can say the Mozilla globally forced extensions are not the issue, then it is not the issue with other extensions either, since I have tested this and gotten it on a clean created profile with absolutely NOTHING changed from out of the box defaults and you get this. So a fair assumption that it is the browser; however, where? I have no clue.
So which errors are the ones you see when you get this problem in safe mode? I would have assumed you wouldn't get the ExtensionUtils.jsm ones but I could be wrong?
|
Reporter | |
Comment 14•6 years ago
|
||
I get the same error and I have no idea to offer as to why an extension error would be included in safe mode but my guess would only be that it is somehow part of the internal workings?
|
|
||
Comment 15•6 years ago
|
||
I was asking which error you care about because there were multiple mentioned. I guess the error that you care about is nsITraceableChannel.setNewListener from the summary?
I'll move this to the networking component as Necko devs may at least have ideas of what would cause this.
|
|
Reporter | |
Comment 16•6 years ago
|
||
I was asking which error you care about because there were multiple mentioned. I guess the error that you care about is nsITraceableChannel.setNewListener from the summary?
Sorry if I misunderstood, it can be related to the tab, networking or the JS engine. Reason I say that is that initially what caused the error that got my attention was that a GM script wouldn't correctly run anymore (aka post WE and 4) and if there was namely a location.href = ... or even a location.assign ... it would hang the tab that initiated it (itself) or nearly have a 90%+ failure (hangs and won't complete the new load), so yes that would imply strongly either a tab state management issue (memory, cache, sandbox, js object, something isn't released right on the same tab reloads or networking, something is not letting something go or terminating in a less than graceful fail.
I hope this helps clarify a bit more, my apologies for missing your intended request initially. Trying to debug this, I started by the usual disable this and that, still persisted, so I decided to disable them all and then try but still no go. So I decided in case there was even the remotest possibility that being disabled is not enough, I ran it in safe mode and that's when the shock came that it does the same thing. The only thing as I said before that I didn't do was to disable the global extensions that are embedded and under the radar within Firefox that are preloaded by Mozilla. Could they be causing this, who knows, I wouldn't know but given there are at least two that have networking and all of them have JS component, it wouldn't surprise me, especially the less than helpful error generated might suggest it was a code that wasn't meant for public consumption per se.
Please let me know if I can provide anything else. Thanks.
|
||
Comment 17•6 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #15)
I was asking which error you care about because there were multiple mentioned. I guess the error that you care about is
nsITraceableChannel.setNewListenerfrom the summary?I'll move this to the networking component as Necko devs may at least have ideas of what would cause this.
AFAICT the error is from here
https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/netwerk/protocol/http/HttpBaseChannel.cpp#3260
i.e. nsITraceableChannel.setNewListener after OnStartRequest
Put back to General since I don't think this is a necko issue
|
|
||
Comment 18•6 years ago
|
||
Hmm… this seems like an extensions or devtools bug but I'm not sure which… I'll start with DevTools.
It seems like setNewListener is being used when tracing isn't enabled. I see two places where it's disabled: https://searchfox.org/mozilla-central/search?q=mTracingEnabled.*false&case=false®exp=true&path=
|
||
Comment 19•6 years ago
|
||
DevTools does use setNewListener. The most likely reason for the stack trace in comment 0 is, I think, https://searchfox.org/mozilla-central/rev/ee3905439acbf81e9c829ece0b46d09d2fa26c5c/devtools/server/actors/network-monitor/network-observer.js#686
(the file name does not correspond to the stack trace anymore because the file has moved recently).
This code normally only runs when the DevTools toolbox is opened though. There is nuance here: the Network panel does not have to be selected or even initialized for this code to run. As soon as DevTools is open, because of these WebExtension APIs the code I linked to runs, so that a DevTools extension could capture network requests.
Could you please confirm that this only happens when DevTools is opened (even in a separate window)?
Also, I'm a bit confused by one thing that you might help clarify: the bug started with this problem only happening on sites that had greasemonkey (or similar) customizations injected. But later you confirmed that it still happened without any extensions applied.
Does it still happen with a freshly installed Firefox? And if so, does it happen on any URL?
|
|
Reporter | |
Comment 20•6 years ago
|
||
Could you please confirm that this only happens when DevTools is opened (even in a separate window)?
Forgive me if I am being stupid but I am not sure how to do that. I mean that when I see this, clearly the DevTool is open because I am accessing the console, hence why I see it. I don't know how to confirm it is happening or not if the window where the only sign of it would show up is not open. Can you please advise.
Also, I'm a bit confused by one thing that you might help clarify: the bug started with this problem only happening on sites that had greasemonkey (or similar) customizations injected. But later you confirmed that it still happened without any extensions applied.
Yes, as I explained before, I was having issues with scripts that had worked fine before and now where hanging on page refreshes, so I spent a lot of time with the console open to try and debug them. This is the reason I came across the errors that I couldn't resolve. It wasn't until later that I wanted to eliminate GM/injected scripts as the issue and so I ran with everything disabled. I thought it would be hard to find them and it was at first but then I realized a pattern and was able to see them happen more on certain types of sites.
Does it still happen with a freshly installed Firefox? And if so, does it happen on any URL?
I will admit the last time I checked was with a couple of release versions back, but to confirm it is still happening or not, try sites that have a HEAVY amount of scripts loading, additionally they are cascaded, meaning they are intentionally bootstrapped to inject later/lazy load after the page has loaded. These would be sites like Bing, Google (services) particularly the angular heavy ones, Facebook, Amazon (services like AWS) with heavy node.js, this seems to be mostly due to how the new type of page designs rely on JS as an engine or ruby style model view and so on. Basically a "full app in a single page style webapps" where they are extremely heavily event driven for everything, meaning pretty much nothing primitive (in terms of pure html) is happening and everything is continually and artificially rendered and displayed.
|
|
||
Comment 21•6 years ago
|
||
(In reply to GµårÐïåñ from comment #20)
I mean that when I see this, clearly the DevTool is open because I am accessing the console, hence why I see it. I don't know how to confirm it is happening or not if the window where the only sign of it would show up is not open. Can you please advise.
Thanks! One follow-up question though: is the toolbox open (the thing that appears inside the browser window by default, and that contains all the panels including console, inspector, debugger, etc.), or are you using the browser console instead (which can be opened with ctrl+shift+J, it's a separate window, with just the console in it)? It does make a difference for what I said earlier about the network observer running or not.
|
|
Reporter | |
Comment 22•6 years ago
|
||
is the toolbox open (the thing that appears inside the browser window by default, and that contains all the panels including console, inspector, debugger, etc.), or are you using the browser console instead (which can be opened with ctrl+shift+J, it's a separate window, with just the console in it)?
I know for certain that it has happened in the toolbox open and all but certain it has also happened in browser console too as I have always used that to debug stuff rather than the web console or than to check network or storage, but I can't say with certainty that I am not conflating with an unrelated use of browser console, I don't want to mislead you. Feeling of certainty here is not equal to actual certainty (where I can point to an actual memory and say emphatically yes).
|
|
||
Comment 23•6 years ago
|
||
Alright, let's move this to the netmonitor component and confirm it, but mark it as a P5 because of the lack of ability to reproduce.
So, the goal here is to solve this specific error found in the logs:
Handler function threw an exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITraceableChannel.setNewListener]"
This is coming from https://searchfox.org/mozilla-central/rev/ee3905439acbf81e9c829ece0b46d09d2fa26c5c/devtools/server/actors/network-monitor/network-observer.js#686
And happens when the toolbox is opened and navigating to certain pages.
|
Assignee | |
Comment 24•5 years ago
|
||
This exception happens much more frequently when fission is enabled and we navigate between two pages loaded in distinct processes.
It relates to network-observer.js code listening to request which started before this code starts running.
|
|
Assignee | |
Comment 25•5 years ago
|
||
This exception happens quite frequently with Fission enabled as we start observing requests
while the page already start loading. This happens frequently when target switching.
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 26•5 years ago
|
||
I'm doing that because previous patch triggered an eslint warning
about _createNetworkEvent being too complex.
|
||
Comment 27•5 years ago
|
||
|
||
Updated•5 years ago
|
|
||
Comment 28•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/b62123491404
https://hg.mozilla.org/mozilla-central/rev/c392ef336132
Description
•