Opened 8 years ago

Closed 8 years ago

#14825 closed Bug (fixed)

[Edge] Dropped support for `setActive` (used to focus editor in some cases).

Reported by: kkrzton Owned by: kkrzton
Priority: Normal Milestone: CKEditor 4.5.11
Component: General Version:
Keywords: Cc:

Description (last modified by kkrzton)

The parent task is #14819.

The newest version of Edge browser (Edge 38.14393, EdgeHTML 14.14393) dropped support for setActive which is used to focus editor in some cases (e.g. divarea plugin) to prevent unwanted scrolling.

While focus should be probably used in this case, it causes this unwanted scrolling so some workaround should be also applied.

Steps to reproduce

  1. Go to plugins/divarea/samples/divarea.html.
  2. Run CKEDITOR.instances.editor1.editable().find('table').getItem(0).scrollIntoView() in the console.
  3. Run CKEDITOR.instances.editor1.focus() in the console.

To check if editor was focused use document.activeElement.

Expected result

Editor should be focused without scrolling.

Actual result

Editor is focused and scrolled to the top.

Other details (browser, OS, CKEditor version, installed plugins)

Edge (Edge 38.14393, EdgeHTML 14.14393)

This issue causes some unit tests fails in:

  • tests/core/config/inline
  • tests/core/dom/documentfragment
  • tests/core/editable/domfix2
  • tests/core/editable/wysiwyg
  • tests/core/editor/title
  • tests/core/filter/editor
  • tests/core/selection/editor
  • tests/core/selection/fake
  • tests/plugins/autoembed/autoembednotifications
  • tests/plugins/floatingspace/floatingspace
  • tests/plugins/image/image
  • tests/plugins/mathjax/mathjax-mock
  • tests/plugins/pastefromword/pastefromword
  • tests/plugins/sourcearea/source
  • tests/plugins/uploadimage/uploadimage
  • tests/tickets/11500/1

At least using focus (instead of setActive) fixes the tests but scrolling problem remains.

Change History (9)

comment:1 Changed 8 years ago by kkrzton

Status: newconfirmed

comment:2 Changed 8 years ago by kkrzton

Description: modified (diff)

comment:3 Changed 8 years ago by kkrzton

Owner: set to kkrzton
Status: confirmedassigned

comment:4 Changed 8 years ago by kkrzton

After further investigating this issue it seems that not the native focus is the reason of unwanted scrolling ( but some custom focus post-logic.

comment:5 Changed 8 years ago by kkrzton

This one was a little tricky to track, but:

  • The scrolling is caused by a native focus call (not by a custom logic as I assumed in a previous comment).
  • The scrolling effect does not occur when debugging via dev console (active breakpoints - pausing the code execution).
  • The scrolling occurs only when focus is executed via code (not initiated by user interaction) - that's why here clicking button does not cause scrolling but timeout call does.
  • The scroll caused by focus happens in async way so the new scrollTop value should be retrieved in a deferred way after focus is called.

comment:6 Changed 8 years ago by kkrzton

Status: assignedreview

Pushed fix to t/14825.

One thing to notice is that the scroll happens only if editor is focused for the first time. If it was focused before, refocusing works as expected.

comment:7 Changed 8 years ago by kkrzton

Status: reviewassigned

comment:8 Changed 8 years ago by kkrzton

Status: assignedreview

comment:9 Changed 8 years ago by Tomasz Jakut

Milestone: CKEditor 4.5.11
Resolution: fixed
Status: reviewclosed

Fixed with git:3f95046.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy