Ticket #6192 (closed Bug: fixed)

Opened 4 years ago

Last modified 4 years ago

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) (diff)

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

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

Change History

Changed 4 years ago by Jude Allred

comment:1 Changed 4 years ago by Jude Allred

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

comment:2 Changed 4 years ago by krst

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

Bug confirmed on Chrome build 6.0.495.0

comment:3 Changed 4 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 4 years ago by Saare

  • Keywords HasPatch added

comment:5 Changed 4 years ago by tobiasz.cudnik

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

Changed 4 years ago by tobiasz.cudnik

comment:6 Changed 4 years ago by tobiasz.cudnik

  • Status changed from assigned to review

comment:7 Changed 4 years ago by fredck

  • Description modified (diff)

comment:8 Changed 4 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 4 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 4 years ago by tobiasz.cudnik

comment:10 Changed 4 years ago by tobiasz.cudnik

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

comment:11 Changed 4 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 4 years ago by tobiasz.cudnik

comment:12 Changed 4 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 4 years ago by fredck

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

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 4 years ago by fredck

comment:14 Changed 4 years ago by fredck

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

comment:15 Changed 4 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 4 years ago by fredck

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

Fixed with [5882].

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