Opened 5 years ago

Closed 5 years ago

#6192 closed Bug (fixed)

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

Reported by: Jude Allred Owned by: fredck
Priority: Normal Milestone: CKEditor 3.4.1
Component: General Version: 3.4.1
Keywords: WebKit Cc:

Description (last modified by fredck)

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.

Attachments (5)

webkit focus.patch (1.3 KB) - added by Jude Allred 5 years ago.
6192.patch (1.2 KB) - added by tobiasz.cudnik 5 years ago.
6192_2.patch (783 bytes) - added by tobiasz.cudnik 5 years ago.
6192_3.patch (1.1 KB) - added by tobiasz.cudnik 5 years ago.
6192_4.patch (1.3 KB) - added by fredck 5 years ago.

Download all attachments as: .zip

Change History (21)

Changed 5 years ago by Jude Allred

comment:1 Changed 5 years ago by Jude Allred

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

comment:2 Changed 5 years ago by krst

  • Keywords Webkit added
  • Status changed from new to confirmed
  • Version set to 3.4.1 (SVN - trunk)

Bug confirmed on Chrome build 6.0.495.0

comment:3 Changed 5 years ago by fredck

  • Milestone set to CKEditor 3.4.1

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.

comment:4 Changed 5 years ago by Saare

  • Keywords HasPatch added

comment:5 Changed 5 years ago by tobiasz.cudnik

  • Owner set to tobiasz.cudnik
  • Status changed from confirmed to assigned

Changed 5 years ago by tobiasz.cudnik

comment:6 Changed 5 years ago by tobiasz.cudnik

  • Status changed from assigned to review

comment:7 Changed 5 years ago by fredck

  • Description modified (diff)

comment:8 Changed 5 years ago by fredck

  • Status changed from review to review_failed

Some notes:

  1. Style:
BAD --> if ( editor.getSelection().getRanges().length === 0 )
GOOD -> if ( !editor.getSelection().getRanges().length )
  1. Considering that the selection is being retrieved in the if(), it should be instead cached in a variable to be reused inside of it.
  1. 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?

comment:9 Changed 5 years ago by tobiasz.cudnik

  • Status changed from review_failed to review

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.

Changed 5 years ago by tobiasz.cudnik

comment:10 Changed 5 years ago by tobiasz.cudnik

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

comment:11 Changed 5 years ago by fredck

  • Status changed from review to review_failed
  • 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.

Changed 5 years ago by tobiasz.cudnik

comment:12 Changed 5 years ago by tobiasz.cudnik

  • Status changed from review_failed to review

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.

comment:13 Changed 5 years ago by fredck

  • Keywords WebKit added; Webkit HasPatch removed
  • Status changed from review to review_failed

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.

Changed 5 years ago by fredck

comment:14 Changed 5 years ago by fredck

  • Owner changed from tobiasz.cudnik to fredck
  • Status changed from review_failed to review

comment:15 Changed 5 years ago by tobiasz.cudnik

  • Status changed from review to review_passed

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

comment:16 Changed 5 years ago by fredck

  • Resolution set to fixed
  • Status changed from review_passed to closed

Fixed with [5882].

Note: See TracTickets for help on using tickets.
© 2003 – 2015 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy