[Safari 7.1+, 8.0] Enter key at the end of block is broken

[zanami]

Safari 8.0 (10600.1.15) on OS X 10.10

I first encountered this on my Drupal 7 + ckeditor installation and then I get the same result here: ​http://ckeditor.com/demo

1. When cursor is at the end of line and I press Enter it moves to the start of the first line (left/top of the area) sometimes (. Also it gets invisible but not always. I think it only misbehaves when there's a tag that ends there.

2. When cursor is anywhere in the middle of any line (or at the end of soft wrapped line) it works as expected on Enter — new paragraph created, cursor is at the beginning.

I made a screenshot to clarify things

[zanami]

Screenshot, how to reproduce

[Piotrek Koszuliński]

It sounds like a serious bug in either new Safari or CKEditor. I cannot reproduce this on Safari 7 and can't test it on OSX 10.10 yet. Could you record a screencast with opened (and visible) JS console?

[Piotrek Koszuliński]

It may be possible to check latest Webkit version using - ​http://nightly.webkit.org/

[Piotr Jasiun]

I tested this bug with WebKit nightly (WebKit r173441), which use AppleWebKit/601.1.1+ and I can not reproduce it there.

[Piotrek Koszuliński]

@zanami: Could you check which Webkit version your Safari 8 uses? You can check this on ​http://browserspy.dk/webkit.php. Just copy us "AppleWebKit version".

[Frederico Caldeira Knabben]

Safari 8 is supposed to be WebKit 538.35.8.

[Piotrek Koszuliński]

So apparently this bug has already been fixed in WebKit.

I'm closing this ticket as invalid, but we can reopen it in the future if for some strange reasons the bug will be back in official Safari 8 release.

[zanami]

WebKit version 600.1.15

Browser using Webkit layout engine? Yes Browser using WebKit layout engine? (via JavaScript) Yes WebKit version 600.1.15 WebKit nightly build No Browser name Safari 8.0 AppleWebKit version 600.1.15 Google Chrome version Unknown or unable to detect Safari version 8.0 User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10) AppleWebKit/600.1.15 (KHTML, like Gecko) Version/8.0 Safari/600.1.15

[Piotr Jasiun]

Confirmed on iPad Air with iOS 8.

[Piotrek Koszuliński]

I can reproduce this issue on AppleWebKit/601.1.1+ ;/.

[Piotr Jasiun]

I tested this with native contenteditable (both inline and iframe) and it works.

[Piotrek Koszuliński]

The fact that native contenteditable behaves better (although, in few minutes I found tests on it too) is not a proof that we can make CKEditor work, because it uses also APIs which may be broken.

[AndiU]

This bug is now in the official Version of Safari 7.1 (9537.85.10.17.1) which is part of regular updates of Mac OS X.

The bug is very critical, as it makes CKEditor totally unusable in Safari :-(

[Piotrek Koszuliński]

Bad news ;/

We were planning to work on this issue this week anyway, but this makes the need for patch even more urgent.

[Robert Emmett]

Bump. Reproducible in Safari 7.1.

[Piotrek Koszuliński]

I pushed ​branch:t/12423 with the patch.

It turned out that on Safari 7 offsetHeight of <br> was 0, but starting from Safari 7.1 offsetHeight equals the line height.

This little changed affected walker.invisible() which then affected the rangeRequiresFix function from selection.js which checks whether range requires fix for the ugly Webkit&Blink bug that doesn't allow to place selection in certain positions. For empty block with a bogus <br> this function should return false, but it started returning true, so the fix started being applied to a case to which it was not supposed to be able to handle.

[Artur Delura]

Merged on ​git:9641ac4

[Robert Emmett]

How soon do you think it will take to be released in a stable build? If not for a while, do you feel that it is stable enough for use in a release product?

[Piotrek Koszuliński]

We are starting today the testing phase for CKEditor 4.4.5 and if it goes well, we will try to release it on Thursday on Friday.

As for the patch itself, it's hard to test it quickly because it's hard to predict what it might affect. But it definitely haven't broken something very badly, because that we would notice, so if you need to fix the bug on Safari ASAP, then you can use it rather safely.

[Piotrek Koszuliński]

CKEditor 4.4.5 has been just released - ​http://ckeditor.com/blog/CKEditor-4.4.5-Released

[The Digital Orchard]

Version 4.4.5 has not fixed this issue for me (Safari 8) as the Change Log claims it to have. Is this still under investigation?

[Piotrek Koszuliński]

Replying to TheDO:

Version 4.4.5 has not fixed this issue for me (Safari 8) as the Change Log claims it to have. Is this still under investigation?

I don't see any problems on Safari 8. Are you sure you checked 4.4.5 (and refresh the cache)?

[Yogesh]

I am using ckeditor 4.4.3,

Where i can find patch file for Ticket #12423

There is no file at the said location "​​branch:t/12423".

[Jakub Ś]

You can see what code got merged here: ​https://github.com/ckeditor/ckeditor-dev/commit/9641ac4.

I think however it is much easier to use new release like CKEditor 4.4.7.

[The Digital Orchard]

Now running 4.4.7 in Safari 8.0.3 (Mac), and while pressing the Return key does indeed behave better, it's still not perfect. Occasionally it will place the cursor back at the beginning of the text again. Is this a bug in the browser or CKEditor?

[Piotrek Koszuliński]

Occasionally it will place the cursor back at the beginning of the text again. Is this a bug in the browser or CKEditor?

We can't say without knowing the scenarios in which the enter key fails. We would need to investigate each case and each case may be different.

[The Digital Orchard]

Just updated to CKEditor 4.5.6, and this problem still exists for me in Safari 9.0.2.

All CKEditor files in my installation are path-versioned so I'm confident that they are not loading old code from the cache.

[The Digital Orchard]

Replying to Reinmar:

Occasionally it will place the cursor back at the beginning of the text again. Is this a bug in the browser or CKEditor?

We can't say without knowing the scenarios in which the enter key fails. We would need to investigate each case and each case may be different.

Here is a simple test that fails for me.

1) Brand new instance on screen. 2) Click into editor... for me it actually takes two clicks (in Safari). The first click does not "stick". 3) Type a line of text. 4) Press Return (Enter) key. The cursor is moved to the top of the document. 5) Manually position the cursor on the second line, and type some more text. 6) Press Return (Enter) key, and the cursor is once again moved to the top of the document.

Completely broken editing experience in my Safari.

[mwhiteley]

By inspecting the changes made to the markup inside the plugin's iframe, the cursor issue occurs when a <p> tag is created with ONLY a <br> tag in it. This seems to be the default markup when creating a brand new default paragraph.

If there is any other content in the new <p> then it works as expected. For example, putting a new line in the middle of a sentence. If it can make a new <p> with other content in then it can move the cursor correctly, otherwise there seems to be calculation failure and it resets the cursor to top left.

This isn't a graphical bug only, any following text input is added to the beginning of the first line. The cursor is actually moved there.

Safari 9.0.2

[blarson_nu]

I'm having the same issue with Safari 9.0.3 on OSX 10.11.3 and I've just upgraded to CKEditor 4.5.7 which is supposed to resolve this issue. How can I get this resolved? It works fine in Firefox and Chrome on 10.11.3 just not Safari. Please advise.

[Jakub Ś]

I haven't been able to reproduce this problem in the same setup.

If you are not using some third-party CKEditor plugin which is causing this then perhaps this is cache issue. Please try clearing it.