So before the question I wanna point out that the only thing I could find on this issue was on this stackoverflow question. This issue suggest that this was an issue with wappalyzer, and it was fixed in version 4.0.1. however I am using wappalyzer version 5.1.4 and is up to date with this.
I am building a web-app based on the MEAN-stack, everything worked as intended for a long time, until this error kept poping up in my google-chrome console:
Everytime i would click in my app header, and use my front-end routing to load up different components / modules this error appears, however I dont see any issue with what the web-app presents to me (it's not like I am missing data)
More details on the error:
I have no idea whats going on, or where this issue comes from.
This was due to a failing plugin.
Disable all plugins, and enable them one at a time to find failing chrome extensions.
In this case it was the wappalyzer extension.
Related
looked for couple of hours, on how to solve that, but no luck.
I am using VS 2017 preview edition, and trying to open ASP.NET core 2.0 web application, that uses Angular template
when i open the site (f5 or ctrl-f5), the web-browser getting opened with the message
Cannot GET /
I don't know what causing that and how to fix that, tried to clean/rebuild/restart VS/change project port number/restart the computer, what else can I do to solve that?
Depending on what error you have in the client application, the server might not start at all. Local errors like undeclared locals are seldom a problem.
Usually, the web server does not start when a dependency of the module marked as bootstrap is missing, like, for example `entryComponents'.
Another thing that can cause the boostrap to fail, is a missing file: in this case you should have a look at templateUrl and styleUrls.
Manually compiling via ng build (or better ng build --prod) will point you to the offending code.
I have a Koa application that has a multipart/form-data file upload that has suddenly stopped working. I have spent over 8 hours now trying to isolate the issue. What I've tried/verified:
Not a Node 6 issue; same problem occurs with Node 4 (which was previously working).
Have ruled out version issues in packages.json; have tested against originally working versions of all relevant packages, and latest versions.
Issue exhibits in latest Chrome and latest Firefox.
Issue does NOT exhibit when POSTing directly from Postman with exact same headers as browser is sending (excepting Cookie and Referer, neither of which can be set in Postman).
Problem exhibits with Koa wrappers koa-better-body and koa-multer.
Problem exhibits when directly using busboy, formidable, and even multiparty.
Similar to problems people were reporitng on this multer issue; tried all suggestions (including the long shot of adding field parameters before file parameter) to no avail.
Have tried to recreate minimal test case to reproduce, but have been unable to.
Have tried whittling down my app line by line, examining Babel output against minimal test case until they are functionally identical, problem still persists in my app, but not in test case.
All tests running on the same server, with the same browsers.
When debugging, the cleanest view of the problem is with formidable, in incoming_form.js. A single data event occurs:
Then an abort event:
After that, the browser eventually times out. (The file is larger than the 15 bytes being received in the first data event.)
I had hoped for a quick fix by switching from formidabl to busboy, and now I am a real bind, because this problem needs to get fixed, and I am running out of ways to look at the problem. I've tried to slice it every way I can think of, debug it every way I can think of, and short of writing my own multipart parser (not a task I would relish), I'm fast running out of options.
Has anyone run across this? Do you have any ideas how I might proceed with debugging or producing a minimum test case?
It turns out the issue was with koa-proxy: it doesn't correctly forward multipart POST requests. I fixed it by switching to koa-proxy2, and I will look into contributing a fix to the koa-proxy project.
Our NoFlo graph components have suddenly compressed themselves all into one uneditable box that says "WaitForward". See attached image.
For a while, this was happening on every browser, except Opera, so I could go in there and update graphs. Then, a couple of weeks later, even Opera wouldn't render the components, so now I am unable to add anymore logic to existing NoFlo forms.
We barely touch code related to NoFlo, so I don't think anything changed in our environment. My theory is that browsers (such as Chrome, which used to be the one stable browser to use for editing) have been updated recently, and this tool needs some kind of an update in order to render properly. Yet I can find no reference to this issue on the NoFlo GitHub instructions, and it doesn't look like anyone is having that issue here on StackOverflow (until now, of course).
The error message in the console says::
"TypeError: this.node.getTransformToElement is not a function"
I plunked this error into Google and saw that others are experiencing this with something called clientIO, and that recent updates to Google Chrome are to blame, as Chrome has recently removed a core feature that allowed related js to function.
But ... how can I fix this? That is the question!
It looks like recent updates to Google Chrome are the culprit.
Taken straight from jointjs.com's website::
Link to announcement from jointjs.com
Announcement: getTransformToElement() polyfill Nov 12th, 2015
Unfortunately, a new version of Chrome (48) removes a feature that is core to JointJS/Rappid. This feature is the SVGGraphicsElement.getTransformToElement() function. The motivation behind removing the method is - according to the Chrome team - open issues about how this method is supposed to behave.
To overcome compatibility issues with future versions of Chrome, we prepared a polyfill that makes sure this method exists. Before a new version of JointJS/Rappid is released (or if you, for any reason, don't want to upgrade), include the following code before you load your application JavaScript:
SVGElement.prototype.getTransformToElement = SVGElement.prototype.getTransformToElement || function(toElement) {
return toElement.getScreenCTM().inverse().multiply(this.getScreenCTM());
};
I was unsure exactly where to put this code in my noflo directory. So I tried putting it at the tippy top of the "app/js/main.js" file. It seems to be working! (But advice for a better location is more than welcome.)
I hope this helps anyone else out there who is experiencing the same issue.
I am asking on behalf of our administrator. Last night the administrator upgraded our production server from 8.5 to 9.01. Today a handful of people using IE 9 are having issues with clientside javascript errors in one application. This problem does not affect all machines, and in fact the application works fine for me when I try it using IE9. In the machines that it fails, it fails every time, in the machines that it works, it works every time. It works for the majority of people. The application works fine in FF and Chrome (insert sarcasm here)
The problems seems to be isolated to one application, an Xpages application that I wrote. It has been deployed for over 8 months and has been very stable until today. I do not believe there is an application problem but here are the errors that it gives
Unable to get value of the property '0': object is null or undefined
This error comes from one of the files generated by the domino server. The file is:
https://my_company/my_app.nsf/xsp/.ibmxspres/.mini/dojo/.en-us/#Im.js
Does anyone have any suggestions on what to do here?
As Steve said in the comments: disable the "runtime optimized JS and CSS" setting as this seems to be an 9.0.1 issue. Facing similiar issues with other frameworks such as Bootstrap 3 where Glyphicons were not rendered properly when this option is activated.
background-position-x is not present in IE9, background-position-y is available. Can it be caused by home-made js animation of css? Have to be manipulated with the single background-position css property instead.
I was developing a Spotify apps and all of the sudden Spotify restarted and updated.
Yey, great.. I got version 0.8.3.222.g317ab79d... however typing spotify:app:the_app_name doesnt work anymore. I get metadataFailed, sorry I could not find this app.
Anyone knows where I can find a downgrade?
Spotify 0.8.3 changed the app lookup slightly. The URI for getting at apps in development is now spotify:app:application-identifier-in-manifest.
This changes the behaviour in old versions, which used the application's directory name to load applications. It's also worth noting that your application must have a valid identifier and version in its manifest.json file. Remember to restart the client when changing your manifest so it notices the changes!
The keys you need to set are BundleIdentifier (which will be used to find the app) and BundleVersion. Documentation on the keys can be found here.
When you check spotify.com you can see there is a be right back message this indicated either server or application failures just hold for a few minutes/hours and return to developing after message is gone.