Hi,
I am getting errors when running cypress tests that look like they are originating in the nrWrapper code:
TypeError: Cannot set property 'status' of undefined
at a (login?l=%2Fmember%2Fsettings%2Fnotifications%3F:541)
at XMLHttpRequest.<anonymous> (login?l=%2Fmember%2Fsettings%2Fnotifications%3F:541)
at XMLHttpRequest.nrWrapper (login?l=%2Fmember%2Fsettings%2Fnotifications%3F:541)
Looks like it starts around here:
t.params.status=e.status;var n=o(e,t.lastSize)
Hey @jblumenfeld, looks like you’re working with the browser agent rather than the Node agent. You might want to see if you can find some help over in the Browser community area.
I have the exact same issue and had to turn off browser agent to make it work.
@jblumenfeld if you find a workaround please let me know. I went to the Cypress chat and this is another possible solution: https://github.com/bahmutov/stop-script - so stopping the script from injecting from within Cypress.
Hi @jblumenfeld,
I got your application’s URL and checked the source code on your login page. I see that you’re using APM injection to install Browser, but it’s injecting our script at the very end of the <head> element rather than at the top, where it needs to be in order to work properly. This may be causing the script to execute very late.
I checked the logic that the .NET agent uses to determine where the script should be injected, and one of the things it looks for to determine the correct placement is a charset tag, which is usually found at the top of the <head>. In your case, this tag is located near the top of the <body> and I think that may be causing the agent to inject the script in a less-than-ideal location. This screenshot shows the tail end of our script and its placement relative to the closing </head> tag and the <body> element:
Would be able to try moving that charset tag to the top of the <head> and checking to see if that moves our Browser script snippet to the top of the head? Once that’s done, generate some traffic and see if you’re still getting that error, and let me know the results. If it doesn’t resolve the installation problems we can engage a .NET specialist in the conversation.
Cheers!
Does this fix the issue on your side @jblumenfeld?
Actually after digging a bit more I found out that using the Lite version of the browser agent does not cause issues anymore.
Also, per one of Cypress’ main engineers:
Somehow New Relic JS agent makes Cypress fail because New Relic and Cypress are trying to stub XMLHttpRequest object in the browser at the same time.
In any case, let us know if moving the script near the fixed it for you. In our case we have in already but its more in the middle, so perhaps we could try to move it up and try again.
Interesting! The lite agent does have fewer features, and no error or AJAX reporting, so if the underlying issue is a conflict between Cypress and our products with regards to XMLHttpRequest that could be why switching to the lite agent addressed it. I’ll see if we have any records of other issues in this area.
Either way, for @jblumenfeld it would still be well worth addressing the installation issue as that’s a frequent cause of agent errors.
Hi Guillaume,
My solution right now is to have cypress listen for exceptions and ignore it if it looks like the same exception. Something like:
Cypress.on('uncaught:exception', (err) => { // returning false here prevents Cypress from // failing the test console.warn(err); if (err.message && err.message.startsWith('Cannot set property \'status\' of undefined')) { return false; } return true; });
We ran this by the Browser engineering team and they took a look. I’ll quote from their findings here:
Cypress.io patches XMLHttpRequest, similarly to the NR agent. However, it modifies the prototype chain, so that the
openandsendmethods cannot be instrumented by us. This has a side-effect of the agent causing an error when tests are run in Cypress. This should not affect production apps, but it will affect customers who are running tests with the NR agent present in their code.
We’ll be adding something on this to our Browser documentation.
Hey there,
We are getting this in our production application at Procore and we are not sure why this keeps reporting so many bugsnag errors.
I am trying to debug the injected script, but I am getting no results understanding the situation.
Why would params be undefined?
t.params.status = e.status;
An example of params
{
host: "sessions.bugsnag.com:443"
method: "POST"
pathname: "/"
}
So it seems to be all the configuration of the XHR request.
I looked for .params and I didn’t see any reset to undefined value, or at lest no direct.
Could you help to fix this issue please, currently is reporting 100K errors per day, also it seems to happen in particular cases.
Is this somehow related to a malformed request or something?
Please help.
Hello Yordis,
I’ve been looking through some previous tickets from customers who’ve reported similar errors when using Browser and Bugsnag together. Our research in the past points to this being a conflict between the two tools (as sometimes happen) but I’ve not been able to find any cases yet with a documented resolution. Our agent is reporting something similar in your application as well:
I also dug around in Insights and found some error events with at least some trace data:
Are you able to reproduce this at all in the live application? I tried to check myself but couldn’t access it.
Hello
We are having this error also. The error is intermittent. I cannot reproduce it myself.
We use Rollbar for error reporting. Can NR conflict with Rollbar?
Hi @aleksandr2,
Unfortunately, I’m not finding much information about Browser and Rollbar not working together in our ticket history. Have you tested this with using the Lite version of the Browser agent or removing Rollbar to see if the errors still occur?
Hello @imattice!
Thank you for response!
We cannot remove Rollbar. It is our main error logging tool.
I will investigate Lite version. What else can cause this error if not Rollbar?
Hey there,
I am sorry I didn’t have the time to respond.
I will be disabling Bugsnag and see how it goes to validate that the integration is the problem today.
Which it actually could make sense, Bugsnag as NewRelic tries to hack all the XHR requests and try to subscribe to global error handling so your tools may conflict with each other.
Let me see how far I can get into this.
It would be really helpful to have an uncompiled version of NewRelic Browser so I can debug easier, so please share it if you can.
Hey @yordis.prieto - Thanks for testing with Bugsnag disabled.
Right now I don’t believe we have a uncompiled version of the browser agent that we can share. But I’ll make sure that the right team knows that there is interest in having that.
Let us know how your test goes.
@RyanVeitch thank you very much for the update,
Regardless,
We disabled Bugsnag wasn’t the issue, and other tools that we thought were causing the issues but it seems that it is not Bugsnag nor the other tool we tested.
It seems to be a particular computer cause all the issues so at this point we are trying to contact the person who owns the computer to understand why this is happening since it is that particular person only (at least from our findings).
Thanks for that info @yordis.prieto I’m curious what you learn from working with that one user. - be sure to let us know 
Didn’t happen 
we had to ignore the error for now.