IE Enter mode + obtrusive bookmarks

[Scott]

When the enter key is pressed in IE, and obtrusive bookmark is created when oRange.Select() is called from FCKEnterKey.prototype._ExecuteEnterBr.

This temporarilly creates a space which is selected, then cleared. This distorts rendering when enter is pressed. I find this particularly distracting when editing large documents on slow computers which take a while to process the enter behaviour.

To replicate this, type a single character into the editor, and press the left arrow (moving to the start of the paragraph). Hold down shift + enter until such time as you see a highlighted space + the character moving 1 char to the right then back again.

I tried setting up something similar to this in fckdomrange_ie.js:

FCKDomRange.prototype.Select = function( bUnobtrusive ) {

if ( this._Range ) {

if( bUnobtrusive ) {

this.MoveToBookmark2( this.CreateBookmark2( true ) ) ;

} else {

this.SelectBookmark( this.CreateBookmark( true ) ) ;

}

}

}

Then calling oRange.Select(true). I realise this changes the method signature of Select() from ie / gecko, but this was more just for testing purposes. This worked most of the time, except for:

- There appears to be an occasional implementation issue with SelectBookmark2() which throws an error - Sometimes the <br /> is created and the cursor is placed after the <br /> node, but the cursor renders on the previous line.

Another fix I found is that oRange.Select generally does not always need to be called for IE from this function. I am unsure, however, if this fixes some edge-cases eg - the cursor occasionally stops blinking, or the cursor shows on the previous line. If there are edge cases like this, perhaps a check should be made, and only call oRange.Select() for IE when absolutely necessary.

I'm quite sure the code which does all this is in FCKDomRange.prototype.SelectBookmark:

dummySpan = this.Window.document.createElement( 'span' ) ; dummySpan.innerHTML = '&nbsp;' ; eStartMarker.parentNode.insertBefore( dummySpan, eStartMarker ) ;

if ( bIsStartMakerAlone ) {

// To expand empty blocks or line spaces after <br>, we need // instead to have a &nbsp;, which will be later deleted using the // selection. eStartMarker.parentNode.insertBefore( this.Window.document.createTextNode( '\u00a0' ), eStartMarker ) ;

}

And selected and removed a few lines later with:

if ( bIsStartMakerAlone ) {

// Move the selection start to include the temporary &nbsp;. oIERange.moveStart( 'character', -1 ) ;

oIERange.select() ;

// Remove our temporary stuff. this.Window.document.selection.clear() ;

} else

oIERange.select() ;

FCKDomTools.RemoveNode( dummySpan ) ;

[fredck]

Patch to minimize the visual effect of the selection

[fredck]

By calling this.MoveToBookmark2 instead of this.SelectBookmark inside FCKDomRange.prototype.Select, you are actually disabling the selection, as MoveToBookmork2 simply moves the Range to the bookmark node, but doesn't select it. It is important to remember that Ranges have nothing to do with Selection.

The fact is that, as strange as that code may looks like, that's the only feasible way we have found to properly position collapsed selections in IE in all situations. We have tried dozens of combinations, and the remained code is the only that worked on all cases.

But, I've just done some tests, and it seams that it is ok if we use a "Zero Width Space" char instead of a "Non Breaking Space" to achieve the selection results, without having the visual selection effect. You may give it a try.

This quite delicate part of the could, that impacts on many situations. As we are about to release the 2.5 Beta, I don't feel comfortable to commit it right now. We'll do that just after the release.

[Scott]

Thats a very good idea with the zero width space char.

I will test it a bit. I was playing around earlier with font styles to acheive a similar result.

Fair enough not to let this sneak into a public beta. I understand that this is a very hot spot in the code which many things depend on.

[Scott]

Actually fredck, it is only this line which causes the visual effect in IE:

eStartMarker.parentNode.insertBefore( this.Window.document.createTextNode( '\u00a0' ), eStartMarker ) ;

I can understand how changing the line:

dummySpan.innerHTML = '&nbsp;' ;

could have adverse effects in IE as it could destroy / randomly clean up selections which dont have entities inside them...

Changing the other one you are simply changing a char code \u00a0 to \u200b. Surely this would not have any effect? Unless something specifically depends on that character.

Can I suggest just committing the char code line? It fixes the problem pretty much perfectly.

[fredck]

In my tests, dummySpan.innerHTML = '&nbsp;' still gave a strange effect. It has nothing to do with the selection effect, but it was adding a space that was visible for a fraction of second. Let's test it better when implementing it.

"Can I suggest just committing the char code line? It fixes the problem pretty much perfectly."

You are tempting me :) But let's wait the release for it. We are playing with IE selection hacks, and this is quite an obscure field.

[Scott]

I just tested this on a different older test computer. It is windows xp sp1, with IE 6. I don't know the reason (whether it be the different version of IE or a different character set), but it puts up a small box where the zero width space should be.

I think this is incredibly strange. I would have thought the character sets would have been the same. Obviously not.

The character &#8203; when just put in source also shows the same box.

Good call on not committing this yet ;)... Something needs to be done about this at some point though.

[Scott]

See attached image.

[Scott]

'ZERO WIDTH NO-BREAK SPACE' (U+FEFF) appears to fix it visually on this computer.

eStartMarker.parentNode.insertBefore( this.Window.document.createTextNode( '\ufeff' ), eStartMarker ) ;

http://www.fileformat.info/info/unicode/char/FEFF/index.htm

This entity is *definately* cleaned up by the browser. IE - if you go to source mode in fckeditor, and insert a few &#65279, they are all gone after switching to design.

[fredck]

I knew that, but somehow I left it happen... I remember I've seen at Wikipedia, the following note about the Zero Width Space:

"it is not supported in all web browsers, most notably Internet Explorer"

So, fortunately you have faced the problem in your test box. Maybe this is a IE6 issue. I've tested it with IE7.

In that same Wikipedia page, we can find other weird space chars. Most probably not all of them are supported.

Then, you came with the "Zero Width No-Break Space". I was tempted to use it, but this is the UTF-8 signature (Byte Order Mask), by many simply known as "those strange  chars". I'm really worried about the way systems handle it inside a stream, so I've immediately ignored it.

If instead we can be 100% sure that the editor will not include this char inside the output, it can certainly be the way to go for us.

Thanks again for your finding Scott.

[fredck]

The "Zero Width No-Break Space" char is definitely the way to go. I've done some checks and it is not in any way outputted by the editor.

I also confirm that the change at line 122 (&nbsp; to &#65279;) is needed to avoid having a white space effect with the same TC.

Fixed with [1029]. Click here for more info about our SVN system.

[Scott]

Excellent! I am glad this is has been committed so that it may be tested and utilized. That selected &nbsp; whenever you hit enter drove me nutters.

Thanks fredck. Add me on msn if you want to and have it - scott_mcnaught@….