[MGNLUI-1582] Rich text editor text selection does not work on iPad Created: 07/Jun/13  Updated: 03/Feb/16  Resolved: 16/Sep/14

Status: Closed
Project: Magnolia UI
Component/s: tablet
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Samuli Penttilä Assignee: Mikaël Geljić
Resolution: Duplicate Votes: 1
Labels: ipad
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLUI-2553 Make sure rich-text editing works aga... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

It is not possible to set cursor position to rich text area. Cursor is positioned always at the end of text. This seems to be problem with CKEditor wrapper and mobile safari. Public demos elsewhere shows same symptoms.



 Comments   
Comment by Samuli Penttilä [ 12/Jun/13 ]

Findings so far:

  • Selection works with plain html page with CKEditor
  • Selection does not work with CKEditor embedded in Vaadin application

CKEditor wrapper for Vaadin was removed and CKEditor was directly added to simplest possible Vaadin application. All layouts were removed and ckeditor was loaded directly. If vaadin bootstrap was disabled the CKEditor selection started working but the rest of course broke.

Because of this it is impossible to say where to file a ticket. It is the combination of CKEditor + Vaadin + iOS

Comment by Samuli Penttilä [ 26/Jun/13 ]

More info: GWT event handling may be the reason why this is happening. Starting the Vaadin framework calls UIConnector.init method where in first line there is DOM.sinkEvents call. When this line is removed the CKEditor works fine with iOS. Unfortunately for us our client side stack contains plenty of GWT event handlers and by removing just this one method call it does not fix the problem with Magnolia environment. Does not seem to matter what events to listen with sinkEvents. Even calling with zero value (clear all events) breaks editor.

Comment by Samuli Penttilä [ 28/Jun/13 ]

Again more info: Its known issue http://openradar.appspot.com/12967017 and can be reproduced with this little html snippet https://raw.github.com/ftlabs/fastclick/master/tests/51-reduced.html If there is any touch event listeners present at DOM then editing text field inside an iframe (CKEditor is such case) will not work.

Couple of discussion threads about the subject:
http://stackoverflow.com/questions/6876706/text-selection-bug-in-mobile-safari-with-iframes-and-ontouchstart
http://stackoverflow.com/questions/6175455/ipad-input-in-iframe

Comment by Samuli Penttilä [ 28/Jun/13 ]

There is couple of alternatives around this issue but not so many pretty ways.

1. Remove all touch event listeners when displaying rich text field. This was the way that thread in stackoverflow was suggesting.

How Safari seems to be behaving is that if parent element has touch event handlers it breaks. Also if sibling elements have touch event handlers and they are (via absolute positioning) placed overlapping iframe element it also breaks. But second approach would be disable touch events for body element only and then move CKEditor as a direct child of body element. Then modality would be implemented by moving all other elements outside viewport. In this case the editor would show up in a same page and text selection could theoretically work.

2. Use some other rich text editor that does not use iframes

3. Refactoring iframe out of ckeditor

  • Cons: may be huge task depending on how architecturally dependent CKEditor is from iframe, is a fork and we have to maintain it.

4. Find a clever workaround
There may be a way with some CSS tuning to fix text selection issues with iframes. Like setting z-index (this example was attempted with no avail). Time and results are uncertain in this option as there is no guarantee that this can be even fixed without modifications to iOS/Safari source code.

5. Open rich text editor in a separate browser tab
Editor instance cannot be run inside Vaadin because GWT will initiate event listeners. Therefore CKEditor <-> Server communication has to be custom made. This has also negative impact on UX as editing is made in another tab.

6. Use source mode to edit
CKEditor uses textarea element instead of iframe in source mode which then works fine with iOS. This solves the problem of text selecting but causes impact on UX since no WYSIWYG. User has to be able to edit HTML. By default source mode disables all buttons so all editing must be done manually. Implementing fix with this option is potentially very easy and quick.

Comment by Mikaël Geljić [ 16/Sep/14 ]

Not worth keeping two tickets for the same thing (see linked MGNLUI-2553).

Generated at Mon Feb 12 08:48:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.