[$20] - Non-critical errors in console when accessing the website

[birdofpreyru]

Just access www.topcoder.com with the dev. console open, and you'll see many errors, which do not lead, though, to any visible errors in the page:

It will be cool, though, to check what is the reason of these errors, and to fix it.

[floweeb]

idk how to really use this github thing... but I'd like to help..... so my question is hoe do I self assign myself this bug

[birdofpreyru]

@Karanja-the-african-hippy Ok, the issue is yours to look into it.

[floweeb]

There are no visible errors on the page as this error is being brought up by the type of browser being used. Even somewhere in the raven.js file there is a comment from its developer saying it may not work on some browsers

. This issue will not affect how the page works as its an issue relating to the developer console. These errors in IE 9 and later are not there at all if you check.
This link may help: https://stackoverflow.com/questions/5472938/does-ie9-support-console-log-and-is-it-a-real-function#answer-5473193

[birdofpreyru]

@Karanja-the-african-hippy Well, actually, I see all these errors in Chrome 55.0 on Ubuntu 16.04. I agree, that I don't see any visible impact of these errors on the web-site behavior, other than spamming the JS console. Though, the idea of this ticket is that it is still not good to have JS errors, even if they have no visible side effects, so we should do something to avoid them. Either refactoring the code in a way supported by all major up-to-date browsers, or extracting this code out to a function, which performs browser checks and makes sure that for each browser it does the job without triggering errors or warnings.

[floweeb]

I think browser checks are the easiest solution but how many browsers are to be included, only major browsers or all possible browsers. Though this is not the best solution, its wouldn't be bad as this functionality is not especially the most important.

[floweeb]

So if I wrote the patch code for this how am I to test it out if its by raven team?

[birdofpreyru]

@Karanja-the-african-hippy Well, actually I'm not quite sure what is the Raven? Can we avoid calling this library on the browsers which have problems with it, or to somehow modify the calls in those cases, to avoid the errors?

About how many browsers, here are the stats: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
Thus, I would really like to see no errors in Chrome. If there is a reasonably easy way to avoid errors in IE, Safari, Firefox, it will be cool as well. But, the number one priority is Chrome.

[birdofpreyru]

@Karanja-the-african-hippy To be honest, I am also a bit sceptical that the only problem with this is that code in that library, as it sounds strange, that something wrote a code for a library, which causes a problem in the major browser.

[floweeb]

`var isChrome = !!window.chrome && !isOpera;	//chrome 1+
var isFirefox = typeof InstallTrigger !== 'undefined';    //Firefox 1.0+ 

//This stops the firefox 1.0+ and chrome 1+ from running this code

if (!(isChrome) && !(isFirefox)){
  
        if (originalConsoleLevel) {
            Function.prototype.apply.call(
                originalConsoleLevel,
                originalConsole,
                args
            );
        }
}`

[floweeb]

this would disallow chrome and firefox from using this code. IE has no errors.

[birdofpreyru]

@Karanja-the-african-hippy I had a look myself, and I believe, it is totally wrong. You click at the link raven.js in the error message in JS console, and it shows you the last code in the call stack, executed before the error message was printed. However, in this case this is actually the code handling errors processing, it does not cause the problem itself. The real problem is hidden somewhere in the callstack.

Are you sure you don't want to pass this ticket to somebody else?

[floweeb]

You can pass the ticket :)

[jsuria]

Hi! I'd like to work on this issue and try to solve it :) Thank you!

[birdofpreyru]

@jsuria Cool! Let's bash this bug :)

[jsuria]

Please set this task as OPEN for now. Something came up and I won't be able to work on this and finish on time. I'll select another task when I get back. Sorry on short notice.

[gets0ul]

Is this still open?
Somehow I cannot assign myself.
Thanks.

[birdofpreyru]

@gets0ul It is yours

[birdofpreyru]

@gets0ul I'm sorry, but just turning off warning messages on unhanded rejections is not what I expected to be done here. It does not fix the problems, it just hides them, and it is even worse.

After looking a bit more careful into the matter, it looks to me that these errors arise when the frontend attempts to interact with some 3-rd party service, related to Raven. It looks that it passes in wrong credentials and thus gets HTTP 403 response, which is not handled, thus the errors, but it does not affect the further frontend performance.

So, our goal here is to (1) figure out what is the service we cannot authorise into, and probably to find out the correct credentials for it; (2) to add proper handling to these rejections. i.e. if my understanding of the situation is correct, and we get HTTP 403 rejection from the request, we should print a human-friendly error message into the console, something like Raven service credentials are wrong. Please provide correct credentials in ..., where ... should be some reference to the repo and code, where these should be provided.

[gets0ul]

It is nothing to do with Raven.
If we disable the Raven, the same error messages are still produced.

Discussion in here, angular-ui/ui-router#2889,
as I refer before in my previous pull request,
offer two solutions:

A workaround, hide those messages as they are missed rejection by ui-router (ui-router's fault)
or,
A fix, Upgrade the angular-ui-router version, as the recent version has those bugs fixed.

I also made additional changes in blog.service.js
replacing the deprecated $http .success and .error as
they are also add unnecessary error messages in console window.

New PR is submitted. #970

[birdofpreyru]

@gets0ul Great! The alternative fix, with the router upgrade and getting rid of the deprecated methods, I like a lot more. Accepted.