Webkit: editor.focus() fails if no selection ranges exist

[Jude Allred]

This causes insertion into the editor to fail.

Repro steps:

1. use Chrome
2. go to ckeditor.com/demo
3. without focusing the editor, attempt to insert a smiley
4. smiley insertion fails. [expected] a smily is inserted.

Ditto for tables, attachments, and all other insertables.

I've written and tested a fix. It's attached as an hg patch file.

[Jude Allred]

Note: The patch is meant to be applied to wysiwygarea/plugin.js

[Krzysztof Studnik]

Bug confirmed on Chrome build 6.0.495.0

[Frederico Caldeira Knabben]

We're definitely having some issue with WebKit selection after [5785]. We have also #6179 and #6178 as well. We need to find a fix for it sooner than later.

[Frederico Caldeira Knabben]

Some notes:

1. Style:

BAD --> if ( editor.getSelection().getRanges().length === 0 )
GOOD -> if ( !editor.getSelection().getRanges().length )

2. Considering that the selection is being retrieved in the if(), it should be instead cached in a variable to be reused inside of it.

3. Strange stuff:

// What's this???
$( doc.$.body ).children()[ 0 ]

Considering the third issue, which should definitely through an error, I'm assuming that if block has never been entered, because I have no errors. So, what's the TC to make it enter there?

Other than the mysterious functions, what if body has no children?

[Tobiasz Cudnik]

It seems this issue can be fixed by only focusing HTML element once.

I've split part of the patch (an IF block) to the #6153. All 3 issues of previous patch have been fixed.

[Tobiasz Cudnik]

When typing #6153, i was thinking about #6178, sorry.

[Frederico Caldeira Knabben]

• There is no need to initialize the wasFocused variable.

• When loading the editor (or switching back from source) with long contents, if you scroll down with the mousewhell and click in a paragraph at the bottom, the caret will be placed there, but the contents will scroll up.

• Let's have a reduced TC for this WebKit issue ​reported at their side as well.

[Tobiasz Cudnik]

Third patch fixes scrolling issue with similar way pasting does.

Unfortunately i wasn't able to prepare reduced TC for this issue, as contenteditable iframe is always focused properly, including when iframe element is generated dynamically. It seems this issue relays on our complex focus logic.

[Frederico Caldeira Knabben]

Not been able to have a reduced tc for this browser issue represents a failure on understanding the root of the problem, not being able to solve it properly.

I've made some investigation on this, opening a WebKit bug for it:
​https://bugs.webkit.org/show_bug.cgi?id=45686

Based on that, I've found out that the fix here was taking the wrong path. I'll provide something different.

[Tobiasz Cudnik]

Your patch is much better than mine for this issue, although we still need the previous one to fix #6153.

[Frederico Caldeira Knabben]

Fixed with [5882].