Internet Explorer 11 SyntaxError in ckeditor.js - javascript

I am getting a weird issue only in IE11 - works fine when I turn emulator on for IE10 - where when I hover over my CKEditor, I receive literally hundreds of SyntaxError ckeditor.js (129,54), sometimes the numbers in the quote is (126,54).
The console errors shows when I hover the mouse into the ckeditor field, and returns a new but same error message every pixel I move the cursor. Hence why in a simple scroll or pass through with my cursor in the ckeditor field, I can get hundreds of errors.
My main issue at hand, is the ckeditor.js file is similar to this - https://cdnjs.cloudflare.com/ajax/libs/ckeditor/4.7.3/ckeditor.js - in that it looks minified. Is there an un-miny version online anywhere?
Secondly, I am posting this to see if anyone has any obvious points I am overlooking, or advice for debugging CKeditor.

Here is unminified version: https://github.com/ckeditor/ckeditor-dev.
You can clone the repository, be sure that you checkout to stable branch such as 4.7.3. Useful might be also install package with npm.
Then take a look into samples folder. There is regular index.html file which use local ckeditor.js, so you should be able to build similar test page for yourself and track the error.

Related

File operations taking long time, receiving "Running [file, save, delete create participants" message

Happening with VSCode version 1.52.1, while working with JavaScript, React, and Node.
I've been working on a React project in VSCode for a couple months now. At some point, in those two months, I started noticing a significant decrease in the speed at which VSCode handles file operations. Like, slow enough that I was creating a single css file, and I went to fill up my water bottle at the cooler and I came back and it still needed about another minute to finish. After browsing some of the VSCode "Issues" on GitHub, I noticed that someone mentioned it might be an issue with the Prettier formatter, but I'm still having the same issue when saving, as well as on file creation and deletion.
*Note: this is my first question, and I need more reputation to directly embed the images
A VSCode prompt box displaying the message "Running 'File Delete' participants"
A VSCode prompt box displaying the message "Running 'File Create' participants"
Things I've tried: Disabling "format on save", disabling all extensions, closing and re-opening VSCode, restarting my laptop
I had the same problem with macOS Big Sur 11.5.1 using VSCode (1.59) and turns out it was (in my case) very simple (basically a newbie problem...). I had been downloaded VSCode and was executing it in Downloads directory. All worked fine but when had to create or rename some file/folder, it took a long time 'Running "File Create" participants' ... After moved the application to Application's folder, the problem was solved.
I had the same issue with Code 1.53.2 on RHEL7. I would perform any file operations within VS Code (save, create, delete, rename), and I would get the Running 'X' participants dialog.
I solved it by downgrading to 1.52.1. Not sure what OS you are running, but it might be worth it to downgrade Code to a version you know was working well for you, and keep an eye on latest development to see if it works itself out.
Hope this helps!
I have encountered the same issue today (Visual Studio Code 1.52.1) while working on CSV and HTML files. Saving a file took like 1 or 2 minutes to finish. I have resolved it by updating VS Code to 1.53.1 version and disabling all extensions.
I have re-enabled extensions one by one to see if the issue came from a specific extension. It still works so far.
even i encoutered the same problem with basic python programs. even creaing new files and deleting them took minutes. it is not about how old or new your machine is. it is about workspace and vs code. when you open a new workspace, vs code runs it in a so called restricted mode where a lot of things are limited. extensions, de-bugging and a lot of other things. on the bottom left of your vscode, click on restricted workspace and then select the 'trust workspace' option. worked for me.
I have this too. In windows, I had drive w: assigned (subst.exe) to my project folder. It started taking a long time to create/rename/delete files. I tried opening directly from the physical drive and it went away. I tried re-assigning w:\ up the file tree a bit and it also went away.
I encountered the same problem recently(in Nov 2021).
I just closed that workspace and reopened same workspace again, and luckily my problem got solved.
I found this bug ticket being reported: https://github.com/microsoft/vscode/issues/128263
What the hell is Running 'File Delete' participants... all about. It
takes several minutes to create a blank file and several minutes to
delete a file. How do I turn off whatever this is. VS Code is basically
unusable with whatever this is enabled.
The solution apparently was this:
Microsoft Live-Share was the culprit. Disabled that and everything is back to normal.
Disable some vs code extensions, one by one as you test, you will surely land on a culprit.
Same is happening with me, I am on iMac, macOS Monterey Version 12.6(21G115):
Version: 1.71.2
Commit: 74b1f979648cc44d385a2286793c226e611f59e7
Date: 2022-09-14T21:05:37.721Z (1 wk ago)
Electron: 19.0.12
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin x64 21.6.0
Sandboxed: No

Vis.js throwing exception after switching to network version

I am using vis.js 4.18.1 currently for a project, which is running on IE11. So far everything worked good, but now I'm trying to add extra functionality for adding edges, etc, and when working on the events, I didn't have my controlNodeDragEnd event fired and I thought its not in my version yet and anyway it would be better to use the latest version (I already had a lot of work done, when i realized I am using the old github project)...So, long story short, I downloaded the latest vis-network.js and the corresponding CSS file. Exchanged it with the old ones and now I get the following error when trying to display my diagram:
SCRIPT5007: Object.getPrototypeOf: 'this' is not an Object
vis-network.js (7074,9)
I am not using npm, I need the js file in my project, am I missing some dependencies maybe?
Didn't change anything else, all my networks were displayed without error in 4.18 and 4.21.
The reason is a known bug, already in progress:
https://github.com/visjs/vis-network/issues/57
Closing question, this should fix it, when finished.

How to force Chrome debugging tools to debug in pretty code?

Although I used pretty code and had set up the breakpoints in "Pretty code" tab, debugger keeps working in minified code. (I can't see exactly where I am and need to continuously switch between source and "pretty code").
On same pages with same script it sometimes work and sometimes don't. I can't find the cause or any difference in the way I activate it.
Is there any way to force debugger to use "pretty code"? Any Ideas or additional questions? Should this be reported as a bug?
EDIT: I still don't understand what is going on but there is a fix for it. So when this situation happens, just edit script and add "debugger;" keyword after the cursor. It will make a breakpoint. Then, if you use "pretty code", debugger will stay inside prettified code. As I said, I don't understand why is this happening so I'm still waiting for answer(s).
EDIT: Current browser version is 42.0.2311.135 (64-bit).
EDIT: Dave pointed out that there is a reported bug on something very similar. https://code.google.com/p/chromium/issues/detail?id=415406 It says it's related to file size but I can't confirm this. I changed title to reflect these findings.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
You can call this a bug. You can call it a dillema.
Open ticket from Aug 9, 2013
(Chrome v. 28)
Bug Reporter's observations
I've been spending some time debugging this, and familiarizing myself
with how to develop devtools locally; I'm not sure if all of this is
helpful, but here's a braindump of what I've looked at so far and some
hunches:
When attaching a breakpoint in the original .js file, the UI seems to
get confused and assigns the breakpoint to the associated .coffee or
.ts file per the sourceMap association [see image-1, attached]
However, when unchecking the breakpoint to disable, the UI correctly
updates to show the breakpoint in the right place in the .js file.
[see image-2, attached]
It seems to me there is either an incorrect lookup happening in
WebInspector.CompilerScriptMapping.rawLocationToUILocation or
WebInspector.CompilerScriptMapping.uiLocationToRawLocation
Open ticket from Sep 21, 2014
(Chrome v. 37)
Chromium Developer's Observation
This is not something that could be solved easily. The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps. Fixing this would require us to use breakpoint's
primary ui location as a hint to where it should be shown. Moreover
since execution line will be shown in the uncompiled sources by
default, it is essential that we keep showing our breakpoints in them
as well. So this all ends up in the need to show breakpoints (and
execution line) on several ui locations at the same time. All actions
with these locations should work smoothly etc.
This is a significant effort and does not sound like a "GoodFirstBug"
to me.
Conclusion:
Prettify does not seem to create a new non-minified version. Rather it is rendered. This makes sense. With all the different frameworks and flavors (e.g. Coffee), if the debugger created a new file, there is high potential for error.
The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps.
I interpret this to mean the Chrome browser and debugger will continue running from the minified version. When you set a break-point in a "pretty" file, the debugger sets it in the minified file and gives the developer a "pretty" rendering of debugger stepping through minified file.
This is a lot for the debugger to manage, and can be rather fragile. We can call this a bug or a very ambitious feature for which many things can go wrong.
**
I have added this thread to both bugs and emailed both developers assigned to it.
**
As of 2020, similar behavior still occurs in a specific situation:
You open a source-mapped document, i.e. it shows "(source mapped from ...)" on the bottom of the window
You prettify it
You place a breakpoint in the prettified version
The debugger will stop in the ugly source-mapped file
The solution seems to be to go to the original source from which you mapped, prettify that, and place the breakpoint there.
Chrome 79.0.3945.88 ; Webpack 4.41.2
Seems like you are clicking the "{ }" (pretty print) icon located in the bottom panel and setting a breakpoints there without attaching a source map of the original file.
When given a .map file, Chrome dev tools and map each line of executed minified code to the original source file using the data in the .map file. Otherwise it will just do it's best to indent/format the minified file.
I suggest you use grunt uglify or similar to minify your js which will automatically generate a map file for debugging. See the following links for more information on how to do this.
http://blog.teamtreehouse.com/introduction-source-maps
Javascript .map files - javascript source maps
How about this?:
Generate the pretty-print version of your "min" version and save using your "min" version name: Substitute the "min" for a pretty "one"
simply put debugger; at top of the js code.
ex:
function add(n1, n2) {
debugger;
let sum = n1 + n2;
return sum;
}
To debug a third-party npm library during local development.
Update package.json from "node_modules[package_name]\package.json"
"main": "dist/package-minified.js" -> "main": "dist/package-formatted.js"
Rebuild your project
You will be able to set a breakpoint to the third-party js library.
Usually, libraries come with both formatted and minified js files. You will find them under node_modules[package_name]
dist/[package-name]-src.js
dist/[package-name]-min.js

The JavaScript language service has encountered an error and has been shut down

Suddenly I receive this error message:
The JavaScript language service has encountered an error and has been shut down.
There is no intellisense in javascript!
What to do?
In my case I have:
Latest VS 2013 Upd.3
Latest Web Essential 2013
Latest ReSharper 8.2.1
Sometimes I see this errors on opening first JS-file after running the solution. I have spent about 2 days on it. Removing Web Essentials helps (also clean the AppData\Local\Microsoft\VisualStudio\12.0\Extensions folder:
extensions.en-US.cache
extensionSdks.en-US.cache
"WebEssentials" folder - it will contain file WebEssentials2013.pkgdef
Then I have tried reset all VS settings and it helped. For a month) Today I have updated solution from the GIT via VS Git Tools (commit contained a lot of JS and CSS changes) and have seen it AGAIN!!!
New solution steps:
Export VS settings.
Reset VS settings
Restart VS.
Check if now it has no any errors.
Import all VS settings EXCEPT Options => TextEditor.
Turn on line numbers for all languages (and if you have some other custom settings - them too)
I don't know who is to blame but I have the fresh Windows 8.1 + fresh VS 2013.
The newest solution steps:
Open the CurrentSettings.vssettings file.
Remove
C:\Users\USERNAME\JsDocComments.js|C:\Users\USERNAME\Modern.Intellisense.js
string from the file
The latest solution steps:
Since I have the laptop with the new clean system w\o this issue I have done the following:
Backed up the PC level ReSharper settings and reset all of them
Reset VS settings with export current one
Restored the PC level ReSharpe settings
Restored the VS exported settings except Options => TextEditor => JS and JS Specific
I have restarted the VS several times and don't see the error now.
Try this solution:
"I was able to fix it: Uninstalling Snippet Designer and deleting the Code Snippets folder on C:\Users\USER\Documents\Visual Studio 2012"
Taken from:
http://social.msdn.microsoft.com/Forums/windowsapps/en-US/d62506a1-4f5f-4013-bcaa-0f827325e424/javascript-language-service-has-encountered-an-error-and-has-been-shut-down
I got this after accidentally copy-pasting a large chunk of HTML into a JavaScript file. Removing said HTML & restarting VS resolved the problem.
In my case, I have Visual Studio 2013 and a Node.js project which is weirdly set up. I just created an empty one and then copied angular-seed into it. So things are not as expected by VS, I guess. I was getting the same error as in the question.
I did not want to uninstal the snippet designer, so I did two things:
I made sure all the snippets in JavaScript folder had shortcuts defined (manually modified xml files) (it was mentioned on the same page Andrea provided link for) - this alone did not help.
I noticed that JavaScript Language Service output widow had a message in it complaining about missing _references.js file. I added the file manually and added only one line to it:
/// <autosync enabled="false" />
Visual Studio stopped complaining about the service failing then. I don't know if fix 2 alone does solve the issue.
ps: I decided to add this info here because this question comes first on Google search for the error. I know it is an old one...
I encountered this issue when I opened a solitary html file.
My workaround is to first open a Solution that contains a web project and then to open a JS file within it. After this, my solitary html file opens without error.
Remove Developer Assistant extension. Work for me

NPAPI plugin problems in Windows 7

I have a NPAPI plugin which I have written and been using for some time with Firefox 3.x with no problems.
The object is defined as follows -
<object class="someClass" id="pluginobj" type="application/x-plugintype"></object>
I then call methods on it using the following format -
if( document.getElementById("pluginobj") != null )
{
document.getElementById("pluginobj").someMethod(someParams));
}
This is how I understand it should be done and has always worked fine. However, I recently installed this same plugin on a Windows 7 machine (with the same version of Firefox) and it now fails to find the functions defined in the plugin, so I get the following error -
Error: document.getElementById("pluginobj").someMethod is not a function
Nothing has changed at all within the plugin, this errors occurs for any method that is called, not a particular one, and it still works fine on Windows XP machines with no problems.
Very confused! Could anyone help? Thanks.
Note: I've also tried logging inside my plugin and it appears it's not even getting in to the NP_Initialize and NP_GetEntryPoints methods.
I have seen some suggestions around that it could be to with dependencies and libraries being linked to the plugin, but i'm not sure what could be missing on win 7?
Dependency Walker is showing a error saying that the "side-by-side configuration information is incorrect"?
Are you linking to other DLL files from your npapi plugin? Windows 7 works differently in how it finds DLL files, though I don't know the details. The times I've seen this with plugins in the past the problem was that on windows 7 one of the dll files couldn't be found. You could try copying dependency dll files to your system32 directory (not permanently, just to see if that's the issue). I would expect that there it would be able to find it.
If that's the issue, I unfortunately am not certain how to fix it, but it might help.
Another possibility based on the side-by-side configuration issue thing is that your visual studio project is creating a manifest that is telling windows that it requires a specific version of one of the DLLs that isn't there on windows 7. See: http://buffered.io/2008/05/17/resolving-side-by-side-configuration-issues/
I think I've resolved that issue in plugins before by disabling the manifest. I'm not sure; I've never had this issue with the way that FireBreath generates npapi plugin dlls, so I haven't needed to worry about it in the last year. You might consider looking at FireBreath, which works on both IE and Firefox (activex and npapi) and has a very good community for tracking down issues like this.

Categories

Resources