I'm currently using this great plugin called HighlightJS for highlighting text on a page when they type in a filter field.
This works great, except for recently we updated from a very old version of jQuery (1.8.2 to 1.11.0) and this no longer works as expected in IE (all versions). It seems to break up single text nodes into a text-node for each searched item. This is problematic when I have it constantly adding & removing the highlighting on a keyup event.
Here's a screenshot of what used to be a single text node now appearing as multiple in the IE11 inspector.
I've put together a demo that breaks in the same way in IE here
Any ideas of how to improve this plugin to make it work as it should? I'll be sure to make a pull request to him on GitHub so others can benefit as well!
I ran into the same issue, and have isolated it to incorrect behavior of the implementation of the native DOM normalize() function in IE11. I've posted some reproduction steps and a workaround on my question:
Why Does IE11 Handle Node.normalize() Incorrectly for the Minus Symbol?
Related
If you add a widget as first element, Ctrl+A will not work in Chrome. If some text is added before, the "select all" works perfectly.
Any workaround?
i'am using ckeditor 4.5.5.
try on Widget Demo.
NB: in Firefox the Ctrl+A works, but a tag <br type="_moz"></br> is added in the first widget.
A problem with selecting content in Blink or WebKit browsers when the widget is the first or last element in the editable area is a known issue and has been reported here: https://dev.ckeditor.com/ticket/11180. As you can see in the ticket report, we were also able to reproduce this problem in native contenteditable elements what indicates a browser bug. Unfortunately we weren't able to find any workaround for this problem and browser vendors haven't provided a fix yet.
NOTES:
Widget demo can be found here: https://sdk.ckeditor.com/samples/simplebox.html. The link you have provided is an old widget preview which is using CKEditor 4.1 (widgets were officially introduced in CKEditor 4.3).
These br's you mention are inserted by Firefox. There is nothing to worry about as they will be filtered out once you obtain the data from the editor using the editor.getData method. Here is a good general explanation of how it works: Want to remove the <br type="_moz"> tag in CKEDITOR 4.2.0
From what I understand, there is no limit in the length of a data attribute(correct me if I'm wrong). However, something strange is occurring in IE when I have a data attribute with a lot of characters. Basically I want to use jQuery to show a specific div if the data attribute, data-zip, contains a specific zip entered by the user.
Everything is working great for me in FireFox, Chrome and Safari, but I noticed that I could not get this to work in any version of IE that I tried(8/9/10). I began to make a JSFiddle, with significantly less zip codes added to the data attribute, so I could post here, but that's when I realized that my Fiddle was working fine in IE as long as the number of characters in the data attribute was kept short.
I also noticed that if I enter all of the zip codes into the data attribute on JSFiddle, JSFiddle thinks that the code is formatted incorrectly (although the code still works as expected in modern browsers so this may be inconsequential).
I used the F12 developer tools in IE to inspect the elements and noticed that when I have all of the zip codes entered, it appears as though none of them are actually being parsed in IE as seen below:
This would probably explain why my code is not working correctly in IE (since the data-zip attribute appears empty). Does anyone know what's going on here and how I can rectify the situation?
Here is a JSFiddle, the first element has the maximum amount of characters I can put into a data attribute, in JSFiddle, before the syntax highlighting gets thrown off, the 2nd shows the highlighting anomaly. Neither of which are parsed correctly in any version of IE I've tried, but in modern browsers it works as expected.
You have to remove the " within the selector to make it work in IE:
So '.contentBlock[data-zip*='+ userZip +']' instead of '.contentBlock[data-zip*="'+ userZip +'"]'. Tested in IE version 9-11 (jsFiddle doesn't work well in IE8).
'[data-zip*='+ userZip +']' will also work, by the way.
I'm having a problem on IE and Chrome when using the jQuery Format Currency and the jCaret plugins.
The problem is described here: http://code.google.com/p/jquery-formatcurrency/issues/detail?id=23&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Opened
When using the fix shown there, format as you type only works on Firefox. On other browsers the cursor stays "blocked" on the input control and you can't select other control. It seems the focus() event is looping.
I've created a jsFiddle to test this situation: http://jsfiddle.net/B3xA6/4/
Help is appreciated on getting this to work (especially on IE).
Thank you
i'm having a problem with the nicEdit script. nicEdit is a javascript libray to set the html textareas of a webpage into Rich Text Format fields.
It works fine except that does not detect when i type the 'space' character. I google'd this and I didn't find any clue. I do exactly what is suposed to do to call the js function:
<script type="text/javascript" src="http://js.nicedit.com/nicEdit-latest.js"></script>
<script type="text/javascript">
bkLib.onDomLoaded(function() { nicEditors.allTextAreas({maxHeight:75}) });
</script>
Is someone having the same or similar problem, or know how to fix this?
edit: I tested it in Google-Chrome and Internet Explorer and the error persists in both.
Thank you very much for your time! :)
I had this same problem, and solved it as follows:
Problem: 'space' wasn't registering in nicEdit fields
Track-down: The actual problem was that a jquery ui feature (accordion in this case) had registered the 'keydown' event for the editors parent. This prevents the 'keypress' event from propagating to the editors registered 'keypress' event handler. I didn't dig deep enough to know why it was only the 'space' key that was failing to propagate.
Solution: I removed the 'keydown' event from the editors parent. in my case that required the following snippet:
$(".accBar,.accContent").unbind('keydown');
I hope this is helpful to someone.
Not solved but guessed the cause of the problem:
I made a simple html document only with a textarea and the javascript invocation of the question and worked fine.
So obviously was not a configuration problem, was some kind of conflict with other javascript libraries i'm using (JQuery and jstree). That is the reason i found nothing on google about it >_<.
My solution was change the nicEdit to jWYSIWYG, a jquery based RTF, and all works fine now.
Are you using a CSS reset? That was my problem - baseline.reset sets some things, particularly revolving around "white-space: normal" that messed up rich text editors. Primarily on windows only, even - so Firefox on mac will work fine, but Firefox on Windows will not be able to make space characters.
The issue was most likely the jsTree hotkey plugin was intercepting spaces and calling "preventDefault". See the issue here:
https://github.com/vakata/jstree/issues/363
Removing the hotkey plugin or commenting out the space hotkey from jsTree should solve the problem.
hey dudes recently i came across a bizzare problem while trying to learn tabbing .. my code worked like charm in firefox and chrome it didn't work in any version of ie ...There will be two tabs and related contents when i click on tab1 corresponding content should be shown hiding other one ..same goes for tab2 it worked in ff and chrome .. but ie add all contents as i switch to other tabs my code goes like this http://jsfiddle.net/myth/PZZ6a/16/
The calls to "getElementsByName" aren't working for you. I think that's because "name" is not a proper attribute for <a> elements, but I have not found any MSDN documentation supporting that notion. The behavior, however, very strongly suggests that that's the case.
edit — well no, it doesn't seem that "name" is improper for <a> elements after all; however, for whatever reason that's the cause of your problems. The calls to "getElementsByName" are returning empty node lists, so your "for" loops don't do anything.
It definitely has to do with getElementsByName not working with the div element in IE. Easy fix though since you already have classes on those two things, use getElementsByClassName.
var tabs = document.getElementsByClassName("tab");
var seltabs= document.getElementsByClassName("seltab");
Working Fiddle: http://jsfiddle.net/CeVa9/1/
Note: Tested in IE9.