nytimes
Pressing "spacebar" while track changes enabled inserts bogus <font> element
Hello -
We are using your ICE extension within the tinymce editor, and for the most part everything is working well. The only issue we have currently is that when a user edits text with track changes enabled, if the first character they input is with the spacebar then a bogus element is inserted into the DOM.
Step 1: suppose there is existing content before the user makes any edits. The DOM looks like the following:
<p>This is my existing text that I previously typed</p>
Step 2: User enables track changes, clicks on the correct element to edit the text, and places the caret after the word "text".
Step 3: The user presses the spacebar to insert a space after the word "text".
When I debugged this in chrome, the call sequence and behavior appeared as expected. We come in through the InlineChangeEditor.keyPress method, and ultimately create and insert the <insert> node. Eventually the stack bubbles back to the keyPress method, and at this point the DOM looks as follows:
<p>This is my existing text<insert ...> that I now modify</insert>...</p>
So far so good.
If we then let the script continue execution back out, something appears to asynchronously insert the following into the DOM:
<p>This is my existing text<font color="#008000">" "<insert ...>
I set a DOM breakpoint to see how that <font> node is being added but it is never tripped.
The end result is that when the text is printed (via pdf) it comes out green, which is not what our users desire.
I have reproduced this in chrome & safari, but firefox does not exhibit this behavior.
Thoughts, ideas, things we should try? Thanks!
strong recommendation: file a bug against the browser. They will have those annoying contenteditable bugs one day. beyond that, we may need to do something in ice in the meantime. What browser are you using?
That's weird! It could be tinymce, too. Have you tried the following version of ice on master:
https://raw.github.com/NYTimes/ice/master/ice-master.min.js
Replace your [TINYMCE]/plugins/ice/js/ice.min.js with that file and let me know if you get the same result. Another test may be checking against a different version of tinymce. We have been testing the latest version of ice on master against the 3.5.x build of tinymce with good results.
@johanneswilm - I was seeing the behavior in both chrome and safari, but not firefox. I haven't tried IE. It may be an issue in webkit. @delambo - I will make sure we are using the version of ice you posted, and will also obtain what version of tinymce we have.
Thanks!
@rjansen72 That is what I was thinking. Both of those browsers have a common codebase, but have recently split so that bugs have to be filed with both. The font-element should never ever appear anywhere, as it's not an HTML5 element. You should file a bug AND personally email the responsible maintainers. Nothing has been changing abotu this for years. For webkit this is Enrica Casucci [email protected] . For Chrome I don't think there is one single person, but if you check out the people posting in this thread of a bug I recently filed, it seems to be made up of the "who's who in the Blink contenteditable world": https://code.google.com/p/chromium/issues/detail?id=238000
You may also consider contacting your senator or the govenor of your state about this. :P