Knockout cyclic error - need advice on finding the cause - javascript

I'm working on a large project with many developers. We have 2 pages using knockout that have been working for a while now. Some new, unrelated code was introduced and come to find out the 2 pages with Knockout no longer work properly. When the pages load, there's an error thrown like below. A little investigating lead me to think there's some kind parsing issue going on in the data-bind attributes. I've tried many things to get it working, but I keep getting the entire view model object returned whenever I try to access an observable property. I think this is what's causing the error I'm seeing below after the page loads.
It's very difficult for me to put examples in here so what I'm looking for is any advice on finding errors JavaScript and/or HTML mark-up that might be causing Knockout to fail.
<error>
(anonymous function)
r.Oa.v
r.i.q
r.a.n
e
h
f
r.R.fn.notifySubscribers
r.a.n
r.R.fn.notifySubscribers
r.w.b.G
b
Array.indexOf
r.a.k
r.T.Ha
b
PriceFormatted.ko.dependentObservable.read
h
f
r.R.fn.notifySubscribers
r.a.n
r.R.fn.notifySubscribers
r.w.b.G
b
Array.indexOf
r.a.k
r.T.Ha
b
// it keeps going from here...

Just wanted to update the answer for this. Unfortunately I didn't track down exactly what the issue was, but it had to do with rearranging the order of referenced script files in the Master page of the app. I reverted back to the original order and the issue went away so it's in fact related to a bigger issue of poorly written custom JavaScript throughout the app.

Related

Issue with Google Tag Manager implementation. "Uncaught TypeError: Wb.set is not a function"

Recently I started having Issues with the Google Tag Manager.
I can't track it to a Tag or a Trigger (activated and deactivated individually to check).
The error started occurring this week (no updates were made to the system or template). I noticed when testing the implementation of a new Tag in GTM. That shortly worked but then this error message started showing in the console. Removing the new Tag didn't change the situation and since the code worked for a while (some 30minutes) I don't expect a direct relationship between the new tag and the error.
All I have is the console in the frontend that shows the following error message:
Uncaught TypeError: Wb.set is not a function
The error stems from this file:
https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX
Wb is started as a Map just a few steps earlier:
Wb=new Map(Vb.h.F);
Wb.set("style",{ya:4});
The GTM Script is copied and pasted from the GTM-Admin without any change made to it and is included in the header.php file of the Wordpress template. I tried copying it again and replacing the script that was in the header.php previously but the result was the same.
If looking at the actual error message in the console helps, the issue can be seen on the following URL:
https://www.bindella.ch
Any help in solving this or at least pointer to where to go look for errors would be very much appreciated.
Thanks
Very interesting, and yes, you're right, the error in the minified code makes no sense:
Let's try something different. First, just export your GTM container (the workspace that is synced with prod/live) as a JSON file in Admin section.
Open the file, look for something like set("style" See if you can find that Wb. Well, don't expect it to be Wb. I guess GTM minifies the code. It may be some weird chat bot, or something like that. From there, you'll be able to find the tag or variable that causes the issue.
I didn't look too deep into it, but that part of code looks sophisticated enough to be a part of the core container code. Actually, we can check it right here, on SO cuz it uses GTM too, let's do that.
Yes, SO has identical code. Looks like it's indeed core GTM. Well, there's a tiny probability that when you built the prod library last time, GTM had an issue and it deployed an artefact.
Try making a new workspace, make a nonsensical change in it and publish it to production. See if it lets you publish. Then see if that fixes the issue.
Now, if it doesn't then the next thing I'd try is trying to re-importing the exported JSON, forcing GTM compare the import to what's there and find differences.
Now if that shows no issues, then I would make a brand new container, load the config in it and try replacing the gtm loading script to see if the error still happens. It sounds like you can do that. If you can't, look a plugin like redirector to redirect the request to a different container.
Still the error with the new container? How about if you load a completely empty container? Got any errors?
There's a very slim chance that your front-end deploys one of a few vars GTM uses too, thus conflicting with your GTM. But it's very unlikely. Why would you use something like google_tag_manager or google_tag_data in the global scope...
If nothing helps and only the empty container doesn't give errors, then... well, then make a list of all tags firing along that error and start disabling them one by one. Or use breakpoints to narrow it down to the tag/library that causes it.

Knockout.js 3.4.1 throws multiple bindings error

I'm working on a rather large project where I use KnockoutJS (large as in it would be impossible to post all related code here), and today I upgraded from Knockout 3.4.0 to 3.4.1. After doing this, I am suddenly getting a multiple bindings-error on every pageload ("You cannot apply bindings multiple times to the same element").
I have been using Knockout for a while, and I am very confident that I am in no way applying bindings multiple times to the same element. I only call applybindings once, and I have confirmed that this statement also only ever runs once by debugging that code (and also searching for any other instances of this function).
After debugging this problem for I while, I decided to downgrade again, to Knockout 3.4.0. And as it turns out, the error is only showing up on the latest build, version 3.4.1.
Anyone else noticed this behaviour? What did they change to cause this?
Even when I run the debug-version of KO, the error can not tell me what element it is referring to, which makes it hopeless to figure out where the error actually comes from.
I am also not using the second optional parameter when calling applybindings (no specific element target), as I am only doing this once anyway.
5 months after your question someone raised an issue with the same problem on their Github page. It was fixed here.
Brian M Hunt's (one of the owners) comment:
The issue was that the valueAccessor() needed to be called (if it's a function) to create the dependency. I believe I have the right fix for it in TKO (basically if (typeof valueAccessor() === 'function') {valueAccessor()()} in the render loop), but the TKO fix doesn't back-port/translate directly since it's using the new binding class style.

BreezeJS RequireJS support unstable (knockout example)

As I'm trying to compile my project with breeze and requirejs for production, I'm running into multiple issues. Unrolling this, I tried starting fresh with the Knockout RequireJS example.
After I installed MVS2013Pro I was able to run the project, but not without issues:
window.breeze is defined so it has been leaked to global scope (this
should not happen with RequireJS)
Hitting F5 Refresh will crash with
Uncaught Error: Can't find breeze and/or Q (breeze savequeuing)
Uncaught TypeError: undefined is not a function (breeze dataservice)
With these errors I'm not even trying to establish my grunt requirejs (r optimizer) task. As these are the root of my problems.
Note: I'm not searching for a knockout solution, my stack actually is: MongoDataService+Breeze+SaveQueueing+RequireJS+AngularJS+Socket.IO+Cordova
window.breeze
You're right that breeze sneaks back into the browser way down at the bottom of breeze.debug.js:
if (global.window) {
global.window.breeze = breeze;
}
We don't know why we put that in the code base. No one remembers. Coming at the end as it does, it clearly isn't needed by Breeze itself.
I commented it out in preliminary testing and that seems to do the trick. The window.breeze becomes undefined in the Todo-KO-Require sample; it remains defined (properly) in samples that do not use require.js.
We don't think this would be a breaking change for anyone ... and the remedy is simple enough: define it yourself at the top of your app.
We'll probably remove these lines for the next release unless we discover a reason to do otherwise.
F5 fail?
I can't repro this at all. I suspect your are conflating your discovery that breeze is inadvertently in the global namespace with your efforts to write an Angular app that uses breeze.savequeuing.js.
Why do I think this? Because the error you describe arises when trying to use breeze.savequeuing.js in an Angular app which is explicitly disallowed in the comments (line #14) of v.1.0.4:
Depends on Breeze (which it patches) and Q.js (not for use in Angular ... yet)
You no doubt omitted Q.js from your required libraries and it all goes to custard from there.
I'm personally allergic to the "save-when-user-changes-anything" user experience that made save queuing necessary. I'm almost sorry I wrote it. But there it is.
The apparently dependence on Q.js is the reason it isn't available for Angular apps as written. It's actually pretty easy to make it Angular-ready now because we recently (quietly) made accessible the component that Breeze is using for promises
breeze.Q // returns the promises component currently used by Breeze
Therefore, you could change the one reference to Q on line #104 to
var deferredSave = breeze.Q.defer();
This should work when using breeze v.1.4.14 and later. I haven't fully tested it yet.
This change (or something like it) likely will find its way into breeze.savequeuing.js v.1.1.0 (as I just pushed a non-release version of that).

What causes Google Maps javascript exceptions?

I pretty consistently get GMaps API javascript exceptions that look like the following:
Ve.k is null or not an object (FF & IE)
b.k is null or not an object (FF & IE)
a is null (FF)
a.$e is undefined (FF)
Uncaught TypeError: Cannot read property 'k' of undefined (chrome)
Often the exception occurs during an eval of some expression in javascript in the bowels of the GMaps API
Almost anything can cause one of these to pop up, displaying an overlay on the map or a mouse click event for example.
I've been scouring my code for some time looking for offending overlays, and event handlers, but so far no relationship found. I've had this happen on a naked map with no overlays or handlers active.
Certain versions of the API will not crash on certain browsers, but it's hit and miss and I still have this sinking susspicion that something in the environment is giving GMaps a hard time (eg. maybe Facebook Connect, Google Analytics, my code...)
Does anyone have a handle on what causes these?
After spending quite a bit of time rolling back operations that affected the map 1 by 1, I finally got to the line(s) that caused this problem.
First, if I removed the call to setUIToDefault() the problem went away, this was unacceptable to me both because I wanted the default UI and that's a lame way to solve the problem. So many more map operations later I came to the GWT calls:
mapWidget.setHeight()
mapWidget.setWidth().
For those not familiar with GWT these two calls will ultimately translate to the following javascript template call:
element.style['height'] = height;
where 'element' in this case is the div that contains the map and height on the RHS of the expression is something like "690px".
That was all it took to derail the maps API.
The fix? Setting the size of the map div prior to instantiating the map.
You tell me, bug in the maps api or just a major feature lack? I'm going to check w/ the maps folks.
Just the perils of using a minified, obfuscated Javascript library I am afraid. There is no discrete group of errors that result in the exceptions you are seeing, but you can be sure that they are a result of a bug in your own code. I use Google maps pretty extensively and have regularly seen these types of errors. In 100% of cases, the bug was mine.
If you post (either here or in new questions) specific examples of pages that generate these errors, we can check them out and hopefully fix them.
I would have to guess it would be your code (not to say your a bad programmer) or another library interfering. I've been using the Google MAPS API happily for about 1 year now* and never had the first exception. The only time I've ever gotten an error message was when I was adding the balloon thingy.
*The website looks like crap but it was a high school project for my county fair and I couldn't use any server side stuff.
Edit: After reading your comment I'm wondering if you included a proper DOCTYPE? Check and see if you have it.

IE Operation Aborted - None of the regular fixes work

First of all, I've been researching this "Operation Aborted" error / bug for what seems like weeks, so here are a couple related questions and good articles if you are not familiar with it:
Why does ASP.NET cause the “Operation Aborted” Error in IE7? (so question)
Detecting cause of IE’s Operation Aborted Issue (so question)
Official Microsoft Knowledge base
Official IE Blog
Now here's my problem:
First I tried moving all my <script> elements to the end of my body tag. Didn't work. Then I refactored all my js functions to an external file that is linked in the <head>, all of my js functions are called from onclick or onkeypress anyway. Still getting the error. The last line of one of my .js files is
document.onload = setTimeout("foo()",500);
so I moved that to <body onload="setTimeout('foo()',500);">. I'm still getting this error. I don't know what to do. The only place I'm editing DOM elements is in foo(). Please help!
About my setup:
Java, Hibernate, Struts, JSPs ... I think that's all that is relevant.
What am I missing here?
Thanks in advance.
There are several causes for this. Two of the most common are:
1) scripts attempting to modify the DOM before the document has completely loaded
2) Trailing commas in object or array declarations
Number two is usually relatively easy to find, while number one is much tougher. Generally the best way to track down IE Javascript problems is to install Microsoft Script Debugger, so at least you can see what lines are causing the problem. With Script Debugger, IE will halt execution inside the browser and kick the script to a Script Debugger console, which will show the problem line. Much more informative than regular IE error messages.
Please see my answer to this question in another thread. I love this little trick and it has never failed me (when the cause is DOM manipulation before IE is ready, I mean). And as written, it doesn't affect the DOM-compliant browsers.
That problem can be a bear on a large page. Beyond the advice in the articles you already have, the only thing I can suggest from here is to remove wide swaths of the page in a dev environment until the problem goes away. Keep refining what is/is not on the page until you know which piece of content is causing the problem.
I've actually seen a confluence between two unrelated page elements cause this problem. I don't remember excisely why but the above approach, although painstaking, still worked.

Categories

Resources