Setting browser to display notifcation for all errors - good idea?

Question

Our product is a web based SaaS application. Internet Explorer has a setting to Display a notification for every script error that QA has turned on (for manual and automated testing). This causes some script errors (mostly javascript) to be displayed that would not be seen with the default browser settings.

Our team is in disagreement as to whether this is a good idea.

What are the possible pitfalls to turning this setting off? One member said that there is a risk that we will allow a number of errors into our code that might not work with some future browser. Then, instead of having a few errors here and there to correct, we will have a large backlog. Is this a legitimate fear?

Can anyone provide examples where ignoring minor JS errors causes larger problems down the road? Can anyone provide counter examples (that ignoring them has caused no issues)? I realize that you can't prove a negative, but a product that has adopted this policy with no problems through several browser version upgrades carries weight in our decision.

Edited to add: There are no user reported bugs for that specify they have used this setting. It is not a default setting, so most end users will not change it. But we are tasked with testing the code, so we turn it on to find all the bugs that we can. There is disagreement within the team as to whether this is a good practice. One side says we should find all the bugs we can and deploy the cleanest code that we can. The other side says that this is a minor issue and we should focus on larger issues (an opinion I can agree with). But the question is whether this policy of ignoring apparently minor errors will later cause larger problems, particularly with accelerated releases of browser versions.

Answer 1

A simple JavaScript error might be a reason of a huge bug. I am always having “Show JavaScript errors” turned on my browser.

Let’s consider the following situation: During saving a Web Form, some JavaScript exception had occurred while populating data from the UI input fields into internal JavaScript object, for instance, JSON object.
In this case, some of the values of the JSON object might be empty or undefined
The JSON object came on the webserver and was successfully saved into the database. Some fields with undefined values were converted to database NULLs. Some important data was not saved and the empty strings were saved instead.

After a month, a manager started a monthly report on the system. As result, the report had incorrect data or was interrupted because of broken data.

The management asks the vendors or developers of the system: “Why doesn’t it work?”

The developers/vendors shrug their shoulders:
“It’s because of incorrect data. We don’t know how it had come there”

In my experience, I’ve seen several times when wrong (incomplete) data was saved into database because of JavaScript exception. It wasn’t created any troubles for the product, because the developers fix such issues immediately.

Answer 2

One of the main things a tester has to do is decide where to focus their limited testing time for the most benefit. If you feel that testing the browser with this mode turned on is an effective use of your time, then go for it, raise the bugs and be prepared to fight for them in the but triage.

From the information that you have posted, this sound like classic "bug hunting", and trying to find as many bugs as possible, regardless of their impact. It feels like this time could be better spent testing or investing that time elsewhere, for example, non IE browsers.

Answer 3

I believe turning OFF to scripting errors or browser notifications could be better idea. Turning them off won't hurt the operation of any program.